Re: Help understanding git checkout behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 11, 2012, 21:34 UTC
Message-ID: <7vk3zd5y8d.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vobop5zmp.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> 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.

So there are two paths involved in this two-way merge.

The master branch (HEAD) has "something", but not "something/f1". The index does not have "something", but has "something/f1". The "b" branch does not have either.

For path "something", the rule 2 in the "Two Tree Merge" section of Documentation/git-read-tree.txt applies. It does not exist in the index, it does exist in HEAD, and it does not exist in the other branch we are checking out. The result should be to remove it.

For path "something/f1", the rule 4 ought to apply. The index entry for it is up to date with respect to the working tree file (i.e. clean), the HEAD does not have it, and the other branch does not have it either. We should be keeping it intact across the checkout. For whatever reason, this is not happening and I suspect that is because we have to remove "something" due to rule 2.

I just checked the history of unpack-trees code (which is the underlying machinery of read-tree, which in turn is the machinery used to check out another branch by "git checkout"), and I suspect that this particular case has never worked.