Junio C Hamano <gitster@xxxxxxxxx> writes: Just a few typofixes... > Johan Herland <johan@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html