Junio C Hamano <gits...@pobox.com> writes:

Just a few typofixes...

> Johan Herland <jo...@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 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.
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

Reply via email to