Re: Difficulties in advertising a new branch to git newbies

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

On Mon, 05 Feb 2007 22:37:42 -0800, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> 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 #2: Type: application/pgp-signature, Size: 189 bytes --]