Carl Worth [off-list ref] writes:
So, could we fix this so that a remote branch name will resolve
without the "origin/" prefix if it is not ambiguous?
I am fairly negative on this one, especially I do not think the
symptom deserves to be described with the word "fix". DWIM is
good, but it has bounds, and this particular one feels it is
slightly on the other side of the boundary. We currently only
DWIM out of a fixed set of patterns -- if you want to extend it,
it would now require readdir() to expand.
I can imagine the resolution rules are already fairly complicated, (I
don't even know what they all are already).
If you add another DWIM rule, then I suspect that you would have
harder time explaining why they get "hey, that is ambiguous"
error.
On Mon, 05 Feb 2007 22:37:42 -0800, Junio C Hamano wrote:
Carl Worth [off-list ref] writes:
quoted
So, could we fix this so that a remote branch name will resolve
without the "origin/" prefix if it is not ambiguous?
I am fairly negative on this one, especially I do not think the
symptom deserves to be described with the word "fix". DWIM is
good, but it has bounds, and this particular one feels it is
slightly on the other side of the boundary.
I can accept that argument.
With "fix" I was referring to the backwards-compatibility problem,
(that I don't have a way to give branch checkout instructions to users
that will work for both 1.5 and pre-1.5 versions of git). As is, if
I provide instructions that don't match the version the user has, then
the user will see a rather confusing message:
git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'origin/8801' which can not be resolved as commit?
[And perhaps the message above is evidence for too much DWIM in the
interface already---that checkout will accept either a revision
specifier or a path name and do fairly distinct operations depending
on which it gets.]
If my tail-matching-for-remotes idea won't fly, are there any other
suggestions for a way to provide instructions for this step that would
work across both 1.4 and 1.5 versions of git?
If you add another DWIM rule, then I suspect that you would have
harder time explaining why they get "hey, that is ambiguous"
error.
Well, ideally git would explain the ambiguity with something like
this:
There are multiple "proposed-fix" remote-tracking
branches. Please specify which you would like:
origin/proposed-fix
something-else/proposed-fix
And I would think that this would not even be surprising since the
user would not get into this situation by default, but would actually
have to have added an additional something-else remote before being
able to get this kind of ambiguity.
But, like I said, I'm glad to accept that the tail-matching idea is a
bad idea. Feel free to drop that on the floor. I'm more interested in
the compatibility issue.
-Carl