GIT bash not recognizing changes to ".classpath" file via "git diff" - windows

I was using command line GIT GNU bash as GIT client, to check in my Java project that I worked on in Eclipse.
As part of the work, I changed some project build settings, which in Eclipse are recorded in a hidden (.dot) file called ".classpath" in the project's root directory.
For some reason git diff refused to recognize the change:
user#HOST MINGW64 /c/_GIT/myserver (BRANCH1)
$ git diff .classpath
<==== crickets. Empty output!!!!
However, I could see that the file changed, with a recent timestamp (and could prove that it changed by explicitly doing git commit and pushing the change):
user#HOST MINGW64 /c/_GIT/myserver (BRANCH1)
$ git commit -m "remove test" .classpath
[BRANCH1 bd4c1c5] remove test
1 file changed, 28 insertions(+)
create mode 100644 .classpath
user#HOST MINGW64 /c/_GIT/myserver (BRANCH1)
$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 610 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Simple Bitbucket Commit Checker
remote: Create pull request for BRANCH1:
remote: http://GIT_URL....
remote:
To http://GIT_URL....
77981fe..bd4c1c5 BRANCH1 -> BRANCH1
GNU bash, version 4.3.46(2)-release (x86_64-pc-msys)

git diff without any options or arguments shows the change between your working tree and the index. Most probably your changes were staged for commit (via git add). You could run git status to verify that. To see such changes (i.e. the diff between the index and HEAD) you should have run git diff --staged.

Related

Xcode Version control: fatal: cannot do a partial commit during a merge [duplicate]

This question already has an answer here:
Xcode Version control: fatal: cannot do a partial commit during a merge?
(1 answer)
Closed 4 years ago.
When using Xcode's Source Control, I get the following error after
pressing commit # Files and Push.
The working copy “Project” failed to commit files.
fatal: cannot do a partial commit during a merge.
I am using Xcode 9+. I have looked here but have not found anything that resolves the issue for Xcode's Source Control.
Thanks for the help.
You will have to use your terminal to resolve this. Xcode (as of Xcode 9) does not support many of the features in git e.g git stash.
Option 1 - Stage changes and commit using Xcode
Following this SO answer, try to stage all the local changes and repeat your steps with Xcode
Open up terminal
Navigate to project directory: cd /path/to/project
Stage all local changes: git add .
Open Xcode and try to commit again.
Option 2 - Stage and commit using terminal
If Option 1 did not resolve the issue, you can complete this task with terminal itself
Open up terminal
Navigate to project directory: cd /path/to/project
Stash your changes (IMP): git stash save name-this-stash
Reset code changes: git reset --hard HEAD~30
Pull the latest state of remote: git pull origin branch-name
Re-apply local changes: git stash apply
Check current status: git status
Stage changes to commit: git add file1 file2
Commit changes: git commit -m "commit-message"
Push changes to remote: git push origin branch-name
Hope it helps!

Accidentally deleted xcode project files via Git commands

I accidentally deleted all my files by committing a new build, then deleting that commit. (git commit -m, git reset -hard HEAD^). Then I tried to use (git merge ) to undo the delete. I noticed that all the missing files were back, but all the contents were missing. To clarify, all the files that were missing after I deleted the commit was back, but contents of those files only included default Xcode markups and all my coding was still missing. Is anyone familiar with an issue like this? Any guidance would be greatly appreciated..
Steps:
git commit -m
git reset -hard HEAD^
git merge
You should be able to use git fsck to see any dangling blobs or commits which remain after a reset.
git fsck --cache --no-reflogs --lost-found --unreachable HEAD
You'll see something like this with any dangling objects:
Then just do git show with the blob id to inspect
git show fd2274ea24e214457fa865e6aa74a0a1b036291a
If it's the file you want, you can then write it to a file using git show {blob id} > filename. e.g.
git show fd2274ea24e214457fa865e6aa74a0a1b036291a > test.txt

Binary file showing as modified after git checkout

For some reason, after cloning a repository and changing branch I had one jar file marked as modified (without being modified) and I can't seem to un-modify the file (which prevents merging branches.
PS D:\src\expm> git status
On branch epic-my-wallet
Your branch is up-to-date with 'origin/feature-01'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: Test/Selenium/selenese-runner.jar
no changes added to commit (use "git add" and/or "git commit -a")
I tried to undo with the checkout command
PS D:\src\expm> git checkout -- .
git status output the same exact message as previously.
I tried to reset it from HEAD with
PS D:\src\expm> git checkout -f HEAD
Your branch is up-to-date with 'origin/feature-01'.
Please note that jar files are flagged as handled by LFS in the .gitattributes file
*.jar filter=lfs diff=lfs merge=lfs -text
Not quite sure on the next step here. The file has not been modified since its commit months ago.
edit
I should add that today we tried to reset the cache with git rm . -r --cached and removed the LFS cache as well (physically remove the .git/lfs folder) and re-download the files with git reset --hard.
Due to your git setting to handle end of line, which should be to 'autocrlf', git modify/corrupt the jar file at checkout!
You should add a '.gitattributes' file in your repository where you set the 'jar' files as 'binary' and git will no more try to convert end of lines.
That's the recommended way to handle end of line in a git repository to solve such problems...
It seem the problem was linked to Git LFS in some way. We upgraded both Git (from 2.8.4 to the current at 2.9.3) and Git LFS (from 1.2.1 locally to the latest 1.3.1 at the moment). Then deleted and re-added the jar file.
We did a clean clone on a new folder after that and the problem seemed to be resolved. Could be the upgrade of git + lfs that resolved the issue.

Why does gitlab freeze when I clone/pull my repo?

i've created a private repo on gitlab.
from my office's macbook i can clone, pull, push and whatever, but here at home (with a little older macbook), when i try to clone the repo, it stuck on "compressing objects" with a different percentage each time...
no matter how big the repo is (i'm trying to clone a 5KB project..)
eg:
git clone git#gitlab.com:username/myproject.git
Cloning into 'myproject'...
remote: Counting objects: 24, done.
remote: Compressing objects: 26% (6/23)
i can leave it here for hours (actually i tried for about 30 minutes..)
but the only thing i can do is hit "ctrl+c" and kill the process, then it says
Killed by signal 2.
fatal: index-pack failed
i'm using:
OSX 10.9.4
git version 1.9.3 (Apple Git-50)
i tried also to create the folder, then
git init
git remote add origin git#gitlab.com:username/myproject.git
git pull
but the result still the same as cloning the whole project
btw.. searching online i found this answer ( https://stackoverflow.com/a/22798706/1294988 ) so i tried to execute:
git clone https://gitlab.com/0X1A/dotfiles.git
and it did it quick and easy! so what's wrong with mine?
any help?

git clone copying some files from other projects?

I've forked a repository, and after doing so, attempted to clone it
$ git clone https://github.com/dax/newly_cloned_project.git
the clone is successful:
Cloning into '[newly_cloned_project]'...
remote: Counting objects: 180, done.
remote: Compressing objects: 100% (143/143), done.
remote: Total 180 (delta 57), reused 144 (delta 21)
Receiving objects: 100% (180/180), 206.54 KiB | 268 KiB/s, done.
Resolving deltas: 100% (57/57), done.
but when change directories to newly_cloned_project, i'm greeted with this:
You are using '.rvmrc', it requires trusting, it is slower and it is not compatible with other ruby managers,
you can switch to '.ruby-version' using 'rvm rvmrc to [.]ruby-version'
or ignore this warning with 'rvm rvmrc warning ignore /Users/charliekim/programming/developer application tasks/connect_four/.rvmrc',
'.rvmrc' will continue to be the default project file in RVM 1 and RVM 2,
to ignore the warning for all files run 'rvm rvmrc warning ignore all.rvmrcs'.
I'm using an .rvmrc file for other projects - but this is newly created and has no such file - upon closer inspection, it turns out that a fair few files are in my newly_cloned_project directory - including an .rspec file and accompanying spec directory...
I've looked around SO and Google but haven't seen any reference to this - I've triple checked my cloning process, so it's no problem there (that I can tell?) really not sure what's going on!
Stupid mistake - if anyone else is having trouble like this, be sure to check that you've not made unnecessary changes to your user level gitconfig file (found at ~/.gitconfig on unix systems).
I had added a remote for a specific repository in this file and that was causing the issue.
~/.gitconfig
[remote "origin"]
url = [email_address]:dax/other_repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
should be in .../other_repo/.git/config

Resources