Re: [1.8.0] Provide proper remote ref namespaces
- From
Johan Herland <johan@herland.net>
- Date
- Feb 3, 2011, 08:46 UTC
- Message-ID
- <201102030946.01086.johan@herland.net>
- In-Reply-To
- <AANLkTi=tMq18mKqr0cp9rXqtDApKu3P_AZGyX6fA3hsx@mail.gmail.com>
On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:
Show 17 quoted lines
> 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