问题
I am on my local my-feature branch
git status reports nothing to commit, working tree clean
I want to switch to develop branch and do git fetch and git merge there (I prefer it over git pull)
However, doing so produces error below
Here I first check status and it shows that all is clean
mymbp:MyProj username$ git status
On branch my-feature
nothing to commit, working tree clean
Next I try to checkout my develop branch which is an existing local branch
On branch my-feature
nothing to commit, working tree clean
mymbp:MyProj username$ git checkout develop
error: Your local changes to the following files would be overwritten by checkout:
MyProj.sln
Please commit your changes or stash them before you switch branches.
Aborting
It complains that myProj.sln has been changed even though git status says nothing has changed.
Issuing git status again, confirms that nothing has changed
mymbp:MyProj username$ git status
On branch my-feature
nothing to commit, working tree clean
UPDATE 1
Doing git ls-files --stage --debug MyProj.sln shows like below and I dont see any 4000 or 8000 (--skip-worktree or --assume-unchanged flags):
mymbp:MyProj username$ git ls-files --stage --debug MyProj.sln
100644 40c3593ed572beb2139c189455274f8900a1340c 0 MyProj.sln
ctime: 1541703970:521058155
mtime: 1541637062:121492660
dev: 16777220 ino: 8470003
uid: 501 gid: 20
size: 55684 flags: 0
mymbp:MyProj username$
Issuing git show develop:MyProj.sln shows me number of project files and their GUIDs in the solution, Global sections for pre and post solution but the output is very long showing just Release, Debug configurations and some GUIDS. Not sure what to do with that yet.
UPDATE 2
So, it seams as if MyProj.sln file is in work-tree but not in index and commit (HEAD). Based on @torek explanation, issuing git add MyProj.sln should add this file to index but that is not true since nothing is added and git status returns nothing before I did git add and after I did it. Meanwhile git checkout still complains that MyProj.sln has changed. git diff also returns nothing
UPDATE 3
I also found someone suggest issuing these 2 command to get hash of commit HEAD and to then see what changed in it. I see lots of files duplicate, while some do not. Those that do not appear to be files I added in my current feature branch. Those that are duplicate appear to be files from remote
mymbp:MyProj username$ git rev-parse HEAD
1ca8d8a7c5eff0f2a03eb185f1b25aff27c1d2fd
mymbp:MyProj username$ git ls-tree -r 1ca8d8a7c5eff0f2a03eb185f1b25aff27c1d2fd
And here is the output of it
UPDATE 4
My config is:
mymbp:MyProj username$ git config --list
credential.helper=osxkeychain
core.excludesfile=/Users/username/.gitignore_global
core.autocrlf=input
difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE"
difftool.sourcetree.path=
mergetool.sourcetree.cmd=/Applications/Sourcetree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED"
mergetool.sourcetree.trustexitcode=true
user.name=User Name
user.email=username@somesystems.com
color.ui=true
color.status.changed=blue normal
color.status.untracked=red normal
color.status.added=magenta normal
color.status.updated=green normal
color.status.branch=yellow normal bold
color.status.header=white normal bold
commit.template=/Users/username/.stCommitMsg
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true
remote.origin.url=https://github.com/SomeSystems/MyProj.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.develop.remote=origin
branch.develop.merge=refs/heads/develop
branch.feat-1.remote=origin
branch.feat-1.merge=refs/heads/feat/feat-1
branch.1234-refactoring.remote=origin
branch.1234-refactoring.merge=refs/heads/1234-refactoring
mymbp:MyProj username$
回答1:
Edit per updates: Something is definitely odd here, though it's hard to say for sure what (the captured output is images so it's not possible to check for weird Unicode issues, for instance). No file should ever be listed twice in git ls-tree -r output on a commit-tree. I have never seen this kind of behavior from Git. There are issues with uppercase vs lowercase, especially on Windows and MacOS, that can cause this kind of behavior, but that doesn't match what you're showing here.
Original answer below
First, a quick note: your tags mention MacOS. MacOS file systems are by default case-insensitive, so that if you have a file named README.TXT and ask the system to view the file named readme.txt, it shows you README.TXT. If you ask the system to add a new file named readme.txt it will instead overwite the existing README.TXT and keep the uppercase name. So watch out for files whose name differs only in case: the Git commit might have a myproj.sln file that will overwrite your MyProj.sln file.
There are at least two possibilities, but let's take the most likely first:
This means there is a file that is not in the current index and commit, but is in the current work-tree, named
MyProj.sln. This same file is in the commit you've asked Git togit checkout. So Git will overwrite the work-tree file if you do successfullygit checkoutthat other commit. Git is warning you that you will lose the current contents of that file.Or, there is a file that is in the current index and work-tree, named
MyProj.sln. The work-tree copy does not match the index copy. Normally,git statuswould tell you that the file is modified, but you've set one of the two index flag bits that tell Git: don't look for changes to the file, and/or don't tell me about changes if you accidentally find some, just keep the index copy around the way it is. These two flag bits are--assume-unchangedand--skip-worktree.
In both cases, if you do successfully check out the commit you're asking Git to check out, that will overwrite the work-tree copy of MyProj.sln. If that is OK, just go ahead and remove the file now, and the git checkout will proceed.
To see which is the case:
git ls-files --stage --debug MyProj.sln
If you get no output, the file is not in the index (and hence also not in the current commit, based on the git status output, or lack of output). That in turn means that it's just an untracked work-tree file at the moment.
If you do get output, it should resemble this output that I get here for a different file:
$ git ls-files --stage --debug Makefile
100644 b08d5ea258c69a78745dfa73fe698c11d021858a 0 Makefile
ctime: <number>:<number>
mtime: <number>:<number>
dev: <number> ino: <number>
uid: <number> gid: <number>
size: <number> flags: <number>
The flags: <number> shows the assume-unchanged and skip-worktree bits, although not in a human-friendly format: skip-worktree is 4000 and the other is 8000 (if both are set you'll get c000). Setting the skip-worktree bit, I actually get:
size: 96311 flags: 40004000
while setting the assume-unchanged bit gives me:
size: 96311 flags: 8000
The commit you're asking to switch to (the tip of develop) has a committed version of the file, which you can see (without having it overwrite the current copy) with:
git show develop:MyProj.sln
Note that once you git checkout develop, that file will be in all three active places: the current commit, the index, and the work-tree. If the tip commit of my-feature does not have the file, switching back from develop to my-feature will remove the file from the work-tree. The way to remember most of this is:
- Commits are made from the index.
- Commits are therefore extracted into the index first (and then on into the work-tree).
- The index keeps track of what's in the work-tree that should be committed. The index copy is the one that goes into the commit.
git statuscompares the index to the work-tree to tell you what you should copy into the index. - When switching commits, work-tree files that aren't in the index, but need to be based on the new commit, get created; files that are in the index, but need to not be there based on the new commit, get removed.
- Files in the work-tree that aren't in the index are untracked, and are left alone.
After that point, the assume-unchanged and skip-worktree bits, if you set them, are just minor tweaks to the otherwise largely self-consistent rules. The .gitignore rules start to make sense as well: a file listed in .gitignore is one that git status won't complain about as being untracked. (However, an important side effect, that .gitignore makes Git feel free to clobber such untracked files in some cases, is tougher to remember, or explain for that matter.)
来源：https://stackoverflow.com/questions/53214095/git-checkout-errors-even-though-git-status-reports-that-working-tree-is-clean