On Mon, 05 Feb 2007 22:37:42 -0800, Junio C Hamano wrote: > Carl Worth <cworth@xxxxxxxxxx> 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. 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
Attachment:
pgpFEaCMFthMl.pgp
Description: PGP signature