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