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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: May 16, 2013, 09:48 UTC
Message-ID: <CALkWK0k=P265MCmvj9C7MFiF=tkhCZ__3oF8FWmWd4sNx3VcTw@mail.gmail.com>
In-Reply-To: <CALKQrgcry9bwmonaeWA4M7a3k36S_Q3ZQLmv7Ui5r+tdzdMr_A@mail.gmail.com>

Johan Herland wrote:

Show 11 quoted lines

> 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?