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 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 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. > I would support disallowing multi-level remote names, although I don't > know if it is commonly used, and would break many existing users. I somewhat doubt it. We very much anticipated the use of multi-level branch names from the very beginning and have support (e.g. in "for-each-ref" and "branch --list") to group/filter them according to prefixes, but I do not think there is anywhere we consciously try to give support for multi-level remote names to treat groups of remotes that share the same prefix. >> *2* Perhaps "bar" in the above is spelled "topics", and the >> hierarchy may be used to collect non-integration single topic >> branches from more than one remote. An example that is more in >> line with such a usage might be: >> >> [remote "jh"] >> fetch = +refs/heads/*:refs/remotes/topics/heads/jh/* >> [remote "jk"] >> fetch = +refs/heads/*:refs/remotes/topics/heads/jk/* >> [remote "fc"] >> fetch = +refs/heads/*:refs/remotes/topics/heads/fc/* >> >> and I would expect "git merge topics/jh/rbranch" to merge the >> "refs/remotes/topics/heads/jh/rbranch" topic branch. > > I like the use case, but not necessarily your expectation. ;-) > > With the above configuration, and my series as-is, you could simply do > "git merge jh/rbranch" to merge the "refs/remotes/topics/heads/jh/rbranch" > topic branch. That dropping of 'topics/' is the issue. The user wanted to group them under 'topics/' hierarchy and made a conscous effort to set up the fetch refspec to map these refs there. These are done all for convenience when she deals with refs in her namespace in the repository. What justification do we have to second guess the user and force her to drop it when naming these refs? > Furthermore, I don't see why you want/need the extra > "heads/" level in the refspec. Just like you wanted to have separate kinds of refs under a single remote, the layout is grouping kinds of refs other than branch heads related to the "topics" (as opposed to "integration branches"). -- 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