Re: [1.8.0] Provide proper remote ref namespaces

On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:

quoted

On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland [off-list ref]

wrote:

quoted

quoted

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