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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

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