Re: DWIM ref names for push/fetch

Daniel Barkalow [off-list ref] writes:

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.