Johan Herland <[email protected]> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
