Duy Nguyen <pclo...@gmail.com> writes: > 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.
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? -- 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