Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2013, 04:28 UTC
Message-ID: <7vr4hmuk20.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1367711749-8812-1-git-send-email-johan@herland.net>

Johan Herland <johan@herland.net> writes:

Show 9 quoted lines

> The "$remote/$branch" syntax can be interpreted in two subtly different
> ways:
>
>  1. A shorthand name for the remote-tracking branch corresponding to a
>     specific $branch from a specific $remote.
>
>  2. A refname fragment, which - when appended to "refs/remotes/" -
>     yields the remote-tracking branch corresponding to a specific
>     $branch from a specific $remote.

I think both of the above are somewhat distorted views and they go against all the documentation we have so far. The real definition is:

   3. $string (which may happen to have one or more slashes) is used
      by prepending a few common prefixes to see if the result forms
      a full refname, and refs/remotes/ is one of the prefixes.
      origin/master ends up referring refs/remotes/origin/master
      because of this.

Show 5 quoted lines

> However, when configuring non-default refspecs
> (such as the +refs/heads/*:refs/remotes/origin/heads/*), it becomes
> obvious that the current code follows the latter interpretation: The
> "$remote/$branch" shorthand will no longer work, and you are forced to
> use "$remote/heads/$branch" instead.

While I do _not_ think it is _wrong_ to use remotes/origin/heads/* as a namespace for branches you copy from the 'origin' remote, my gut feeling is that it is myopic to redefine that origin/master resolves to refs/remotes/origin/heads/master [*1*].

Step back a bit.

There must be a reason why somebody wants remotes/origin/heads/* instead of the traditional remotes/origin/* to keep the copies of branches taken from the origin.

It is because she wants to use the parts of remotes/origin/ that are outside remote/origin/heads/ to store other things taken from that remote, no? They may be "changes", "pull-requests", "notes", etc.

If origin/master were to map to refs/remotes/origin/heads/master and origin/jh/rtrack were to map to refs/remotes/origin/heads/jh/rtrack, [*2*] what short-hands hierarchies in refs/remotes/origin/ other than "heads/" would have?

If you do not special case "heads/",

    $ git merge origin/pull-requests/4

is very straightforward to understand and explain when you use the definition #3 above. But if you do, then the above may refer to origin/heads/pull-requests/4, or perhaps there is no pull-requests/4 branch in the origin and the resolution may have to error out.

While I do not reject refs/remotes/origin/heads/* layout as a possibility, I am somewhat skeptical that any "solution" that starts from the "two interpretations" above (both of which are flawed, that only consider what happens to the branches) will yield a generally useful result.

If the final end result you are shooting for is to introduce an extra level between the remote name and the branch names, i.e. "heads/", any solution needs to at least have a plan (not necessarily a detailed design or implementation) for the other hierarchies. The possibility to have these other hierarchies per remote is the true progress that the "heads/" at that level can give us; there is not much point to have heads/ after refs/remotes/origin/, if heads/ is the only thing that can come there.

[Footnotes]

*1* Unlike the usual cautions from me, this does not have anything
    to do with backward compatibility; it is more about forward
    thinking.

*2* Wait.
    Does origin/jh/rtrack map to refs/remotes/origin/jh/heads/rtrack
    which is rtrack branch taken from the origin/jh remote?