Re: DWIM ref names for push/fetch

On Sun, 24 Jun 2007, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

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.

Ah, okay. I think a few bits got lost somewhat in Julian's translation to 
C. I agree with the first three rules there, and with the last rule being 
the last rule, and sticking more things in between those sets is easy 
enough.

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

quoted

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.

Currently, it doesn't even notice if you've got the tracking branch 
already. Should it have some rule to prefer things that exist over things 
that don't?

When refs/remotes/origin/next doesn't exist, should it require that 
refs/remotes/origin/ already exist?

In any case, the big question is whether the push code should use these 
rules, too, for the corresponding portions, in which case I can share the 
code (and, for that matter, the documentation, which would be even nicer, 
because we've currently got a lot of hints about refspecs in different 
places but nothing complete anywhere).

	-Daniel
*This .sig left intentionally blank*