Re: [1.8.0] Provide proper remote ref namespaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@xxxxxxxxxxx> 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.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]