Re: [RFC] git checkout $tree -- $path always rewrites files

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 9, 2014, 18:37 UTC
Message-ID: <xmqqh9y8b4pi.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141108084526.GA18912@peff.net>

Jeff King <peff@peff.net> writes:

Show 23 quoted lines

> On Sat, Nov 08, 2014 at 03:30:40AM -0500, Jeff King wrote:
>
>> So just to be clear, the behavior we want is that:
>> 
>>   echo foo >some-new-path
>>   git add some-new-path
>>   git checkout HEAD -- .
>> 
>> will delete some-new-path (whereas the current code turns it into an
>> untracked file). What should:
>> 
>>   git checkout HEAD -- some-new-path
>> 
>> do in that case? With the current code, it actually barfs, complaining
>> that nothing matched some-new-path (because it is not part of HEAD, and
>> therefore we don't consider it at all), and aborts the whole operation.
>> I think we would want to delete some-new-path in that case, too.
>
> Also, t2022.3 has me very confused.
>
> It is explicitly checking that if we have "subdir/foo" unmerged in the
> index, and we "git checkout $tree -- subdir", and $tree does not mention
> "foo", that we _leave_ foo in place.

The definition of how "checkout $tree -- $pathspec" should behave logically leads to that, I think. Grabbing everything that matches the "subdir" pathspec from $tree, adding them to the index and checking them out will not touch subdir/foo that does not appear in that $tree.

With the proposed updated semantics, it would behave differently, so it is natural that we have tests that protect the traditional definition of how it should behave and we will have to visit them and update their expectation if we decide that the proposed updated semantics is what we want.

> That seems very counter-intuitive to me. If you asked to make "subdir"
> look like $tree, then we should clobber it.

Yes.  But the existing expectation is different ;-)

If the $tree has 'subdir/foo', we would want "checkout $tree -- subdir/foo" to keep working as a way for the user to declare the resolution of the ongoing merge. With the proposed change in sematics, "git checkout $tree -- subdir" will become a way to say "Everything inside subdir/ I'd resolve to the state recorded in $tree" during such a conflicted merge, and it will lose paths not in the $tree.

Which may be a good thing, but existing users who are used to the traditional behaviour will find it confusing and even risky (i.e. "I am checking OUT; never expected it to lose any path"). A counter argument that I find sensible, of course, is "You told us to check out subdir/, and the state recorded for subdir/ in $tree does not have 'foo' in it. That is the state you asked us to check out".

The argument for "checkout $tree -- subdir/foo" is essentially the same. The state recorded in $tree for subdir/foo is non-existence, and that is checked out with the proposed new semantics.