Jonathan Nieder <jrnie...@gmail.com> 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) */
> 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> [--]
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