Re: DWIM ref names for push/fetch

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 25, 2007, 06:10 UTC
Message-ID: <7vodj4o973.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0706242234250.4740@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 7 quoted lines

> I was actually thinking exclusively of the matching of strings like "HEAD" 
> or "origin/next" or "master" to refs from the list of available refs. It 
> seems to me like the push code does a better job of handling the same 
> sorts of things that get_sha1() handles.
>
> In particular, the handling of "refs/my/funny/thing" is really wrong: it 
> gets treated as refs/heads/refs/my/funny/thing.

git-parse-remote.sh::canon_refs_list_for_fetch() seems to say otherwise, though.

 - When unspecified, or explicitly spelled HEAD, take HEAD;
 - Anything that begins with refs/, use it as is;
 - Anything that begins with heads/, tags/, remotes/, assume
   it is a branch, a tag, or a tracking branch;
 - Otherwise assume a branch;

So I suspect refs/my/funny/thing is covered by the second rule.

But I do agree "otherwise assume a branch" part has huge room for improvement. Especially...

> I think that "origin/next" 
> should also be assumed to be refs/remotes/origin/next instead of 
> refs/heads/origin/next, at least if you have refs/remotes/origin/ and not 
> refs/heads/origin/.

... I think that makes perfect sense -- the code should interpret your example as a request to start using a new tracking branch refs/remotes/origin/next.