Re: Help understanding git checkout behavior

Cláudio Lourenço <pt.smooke@gmail.com> writes:

Not really. In general, "git checkout b" (no path arguments, checking out the branch "b") will try to keep the local changes you made to the index and to the working tree for a path that are the same between your current branch and the branch "b". So it is perfectly normal to see:

        $ git checkout master
        $ git ls-files file
        file
	... ok, the master branch has "file"
	$ git diff master side | grep file
        ... ok, the side branch also has it and it is the same
        $ git rm file
        $ git checkout side
	D	file
	Switched to branch 'side'

So it actually _actively_ pays attention to paths deleted or modified in the index.

Another thing it does is when the local change to the index matches that of the branch you are switching to, checkout is allowed even if path is different between two branches.

When checking the differences between the two branches (the current and the new), unpack-trees notices that the path "something" is not present in "b" branch, and even though your current branch and the index differs (the index does not have "something" as you have removed it), it thinks it is OK for the result to not have it (which is correct). And when it does that, it forgets that a new path "something/f1" still needs to be kept (which is not correct), which is where the problem you are seeing comes from, methinks.