On Wed, Aug 24, 2016 at 11:35 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy  <pclo...@gmail.com> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to