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).
> 
> How about convert old style remotes to new style? Should it be done
> automatically when new git detects old style remotes, or done by
> command, or manually?

I don't think we want to mess with existing remote refs without the user's 
consent, especially since the user might have all kinds of repo-specific 
practices tied to the old layout of remote refs.

Providing a command to do it (git remote renew?) is a much better way to go 
about it, IMHO. Still, it is vitally important that new git keeps working 
with old-style remotes.

Another issue is whether we should automatically make the old-style implicit 
refspecs into _explicit_ (but still old-style) refspecs. I.e. when 
encountering an old-style remote, new git could automatically add the 
following refspecs to the remote:

	+HEAD:refs/remotes/origin/HEAD
    ~refs/tags/*:refs/tags/*


...Johan

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