On Thu, Feb 3, 2011 at 9:10 PM, Santi BÃjar <santi@xxxxxxxxxxx> wrote: >> On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote: >>> 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. > > 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. Personally I don't have any repos that weird, so it's no problem to me. Maybe I'm overengineering. -- 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