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

Junio C Hamano [off-list ref] writes:

Just a few typofixes...

Johan Herland [off-list ref] writes:

quoted

Let me try to summarize my views on how refnames should work in Git, to
see if we can identify where we differ on the principles (or if we, in
fact, differ at all):

Thanks; I think I already said where I think we differ in a separate
message, but a short version is that the point of remote.$nick.fetch
mapping is to solve "The remote may call a ref $this, which is not
the refname I want to or can use in my repository, so here is the
rule to use when importing it in my local namespace.  With the
mapping, I can name the ref in my local namespace conveniently."
E.g. their "refs/heads/master" cannot be our "refs/heads/master" at
the same time, so use "refs/heads/origin/master".

The last should be "refs/remotes/origin/master".

The result of the above mapping, be it remotes/origin/master or
remotes/origin/heads/master, should be designed to be useful for the
local use of the ref in question.  If you further need to remap it
when using it locally, there is something wrong in the mapping you
defined in your remote.$nick.fetch mapping in the first place.

We do not force any structure under refs/remotes/; it is left
entirely up to the user, even though we would like to suggest the
best current practice by teaching "clone" and "remote add" to lay
them out in a certain way.

Another thing is that refs/remotes/ is not special at all.  If notes
hierarchies taken from a remote need to be somewhere other than
refs/notes/, it is perfectly fine to introduce refs/remote-notes/ if
that is the best layout when using them locally.  What is special is

s/the best/the most convenient/;

refs/heads/ in that they are the _only_ refs you can check out to
the working tree and directly advance them by working on the working
tree files.