Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > case 3: git checkout <something> [--] > > If <something> is a commit, [...] > > If <something> is _not_ a commit, either "--" is present or > <something> is not a path, no -t nor -b was given, and [...] > > Otherwise, if "--" is present, treat it like case (1). > > Otherwise behave like case (4). Actually, no. Below, we have /* * Do not complain the most common case * git checkout branch * even if there happen to be a file called 'branch'; * it would be extremely annoying. */ Which is a subcase of (3). The guess done in (3) is permissive, and the one done with more arguments (4) is strict. > case 4: git checkout <something> <paths> > > The first argument must not be ambiguous. I wasn't very convinced by your version at first, but I gave it a try. I'm not sure the comment is actually better now, but I think it exposes the complexity of the guess, and the difficulty to map the code and the comment more. Other people should take this as an incentive to improve the situation (but I'm really getting short of Git time budget, sorry). > Then can come the "invalid reference" check for case (1): > > } else if (has_dash_dash) /* case (1) */ > die(...); > > Then case (4). > > else /* case (4) */ > return argcount; Actually, the comments are wrong here. The comment <-> code mapping is more complex than this. At this point of the code, you know that the first argument is not a commit, and that dwim has been ruled-out. But that may be case 3 also: git checkout --no-guess <non-branch> [--] -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html