On Thu, May 16, 2013 at 11:48 AM, Ramkumar Ramachandra <artag...@gmail.com> wrote: > Johan Herland wrote: >> The disambiguation can probably be resolved, although the resulting >> code will obviously be somewhat more cumbersome and ugly (and IMHO the >> current code is plenty of that already...). Combine this with the >> problems of clobbering of the same remote-tracking ref (describe >> above), and the fact that AFAIK a multi-level remote name has never >> been observed "in the wild" (none of the people I asked at the Git >> Merge conference had ever observed multi-level remote names, nor did >> they directly oppose banning them), I'm not at all sure it's worth >> bothering about this at all. Simply disallowing multi-level remote >> names seems like the simpler and naturally ambiguity-resistant >> approach. > > The problem with multi-level remote names is that we use the same > delimiter as in the ref namespace: '/'. So, obviously, there's a lot > of room for confusion. I wonder if we should banish multi-level > remotes altogether though: is it possible that they will be useful to > someone in the future?
Technically, the problem is that we don't use a different delimiter between the $remote and $ref parts. If we had used "multi/level/remote:nested/ref" we would have been OK (on this issue at least, probably not OK on other issues). FWIW, I've abandoned this patch, and don't care much about multi-level remote names anymore. They work in current git, and they will sort-of work with remote ref namespaces as well, although you will have to use full refnames when referring to their remote-tracking refs. If multi-level remote names suddenly become popular, we can change the code to try to resolve them unambiguously. ...Johan -- Johan Herland, <jo...@herland.net> www.herland.net -- 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
