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

[Junio C Hamano <gitster@pobox.com>]

Johan Herland <johan@herland.net> writes:

> 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.

> 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?