Re: Help understanding git checkout behavior

From: Jeff King <peff@peff.net>
Date: Jun 11, 2012, 21:47 UTC
Message-ID: <20120611214705.GC32061@sigill.intra.peff.net>
In-Reply-To: <7vk3zd5y8d.fsf@alter.siamese.dyndns.org>

On Mon, Jun 11, 2012 at 02:34:42PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> 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 think the problem is in verify_clean_subdirectory, which checks that we do not have untracked files in the subdirectory, nor modifications between the index and working tree. But I do not see it checking whether we have modifications from the HEAD.

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

Yeah, I verified it back to v1.6.x, but didn't bother going further back.

-Peff