Re: [1.8.0] Provide proper remote ref namespaces

From: Santi Béjar <santi@agolina.net>
Date: Feb 3, 2011, 14:10 UTC
Message-ID: <AANLkTindnAFix+u3HKW0V-ArkzjyrDhpmN6gf9PSj0_G@mail.gmail.com>
In-Reply-To: <201102031410.58623.johan@herland.net>

Show 21 quoted lines

> On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:
>> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net>
> wrote:
>> > Migration plan:
>> > ...
>> > In v1.8.0, we should default to the new default refspecs when
>> > creating new remotes. However, existing remotes (created
>> > pre-v1.8.0) must continue to work as before, so we cannot simply
>> > remove the implicit refspecs (or tag auto-following). Instead we
>> > need to make sure that the implicit refspecs is NOT applied to the
>> > new-style remotes. Identifying new-style vs. old-style remotes can
>> > be done by looking at the refspec itself (old-style:
>> > "refs/remotes/$remote/*", new-style:
>> > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a
>> > config variable specifying the desired behavior (defaulting to
>> > old-style).
>>
>> I'd prefer config var (remote.*.implicitRules, maybe). We don't
>> reserve heads, tags... in remote namespace for ourselves. Some users
>> might have already have branches heads/ant, heads/bee... making new
>> style detection unreliable.

I don't quite follow the argument. For me the question is how likely an old-time user has modified the refspec to read "refs/remotes/$remote/heads/* (new-style). I think this is very, very unlikely and thus the "heuristic" to detect old/new style works most of the time and there is no need for a new config/compatibility key.

HTH, Santi