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