Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland <johan@herland.net>]

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.
>
> So I propose add remote.*.implicitRules = false since 1.8.0 for new
> remotes as a way to detect new/old style. The default value would be
> true.
>
> But I don't want to keep adding remote.*.implicitRules on new remotes
> forever. I suppose one year after 1.8.0, the new behavior is
> widespread enough. We can then annoy users to add
> remote.*.implicitRules for all old remotes. There should be no more
> default value after 1-2 years. We then flip the default value and
> won't automatically add remote.*.implicitRules = false on new
> remotes.

I don't have a problem with this, other than bikeshedding over the 
variable name: I find remote.*.implicitFetchRefspecs more descriptive.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net