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

> Johan Herland <johan@herland.net> writes:
>
>> 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 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