Subject: Re: [PATCH] checkout: swap the order of ambiguity check for :/ syntax

From: Junio C Hamano <[email-masked]>
Date: Thu, 25 Aug 2016 10:19:40 -0700

Duy Nguyen <[email-masked]> writes:

> On Wed, Aug 24, 2016 at 11:35 PM, Junio C Hamano <[email-masked]> wrote:
>> Nguyễn Thái Ngọc Duy  <[email-masked]> writes:
>>
>>> It's not wonderful, but it's in line with how git-checkout stops caring
>>> about ambiguity after the first argument can be resolved as a ref
>>> (there's even a test for it, t2010.6).
>>
>> But that is justifiable because checkout can only ever take one
>> revision.  What follows, if there are any, must be paths, and more
>> importantly, it would be perfectly reasonable if some of them were
>> missing in the working tree ("ow, I accidentally removed that file,
>> I need to resurrect it from the index").  Does the same justification
>> apply to this change?
>
> I think there is a misunderstanding. My "after" is in "after the first
> argument can be resolved, check if it exists in worktree too, if so
> it's ambiguous and bail". This is usually how we detect ambiguation.
> But git-checkout does not do the "check if it exists..." clause.

Hmph.  The "case 4" in the function you touched says

         * case 4: git checkout <something> <paths>
         *
         *   The first argument must not be ambiguous.
         *   - If it's *only* a reference, treat it like case (1).
         *   - If it's only a path, treat it like case (2).
         *   - else: fail.

Did we break it recently?