Re: [PATCHv2 04/10] remote: Reject remote names containing '/'

From: Johan Herland <johan@herland.net>
Date: May 16, 2013, 11:17 UTC
Message-ID: <CALKQrgewHCrkf0kP57Mm+werT9yAWnLZP7CJn-k3g85gfPRspA@mail.gmail.com>
In-Reply-To: <CALkWK0k=P265MCmvj9C7MFiF=tkhCZ__3oF8FWmWd4sNx3VcTw@mail.gmail.com>

On Thu, May 16, 2013 at 11:48 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 18 quoted lines

> 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, <johan@herland.net>
www.herland.net