On zo, 2013-06-23 at 15:33 -0700, Junio C Hamano wrote: > Dennis Kaarsemaker <dennis@xxxxxxxxxxxxxxx> writes: > > > On zo, 2013-06-23 at 14:22 -0700, Junio C Hamano wrote: > >> Dennis Kaarsemaker <dennis@xxxxxxxxxxxxxxx> writes: > >> > >> > Equality for > >> > wildcards is allowed and tested for, so do we really want to 'outlaw' > >> > equality of non-wildcard refspecs? > >> > >> I am not sure what you mean by "equality for wildcards is allowed". > >> Do you mean this pair of remote definition is sane and not warned? > >> > >> [remote "one"] > >> fetch = refs/heads/*:refs/remotes/mixed/* > >> > >> [remote "two"] > >> fetch = refs/heads/*:refs/remotes/mixed/* > > > > I personally don't consider them very sane and didn't originally support > > that. But this behavior is tested for in t5505-remote.sh test 27, which > > started failing until I stopped warning for equal refspecs. This support > > for "alt remotes" in prune was added by c175a7ad in 2008. The commit > > message for that commit give a plausible reason for using them. > > I actually do not read it that way. What it wanted to do primarily > was to avoid pruning "refs/remotes/alt/*" based on what it observed > at the remote named "alt", when the refs fetched from that remote is > set to update "refs/remotes/origin/*". > > The example in the log message is a special case where two > physically different remotes are actually copies of a single logical > repository, so in that narrow use case, it may be OK, but it is an > unusual thing to do and we should "warn" about it, I think. Apart from the exactly matching refspecs, does git in any other way treat this as a special case? > In any case, I've been assuming in this discussion "allow" is to > silently accept, and overlaps are "warned" but not "rejected". So > if you meant by 'outlaw' to die and refuse to run, that is not what > I meant. Well, 1/3 is a warning on add, 3/3 is a warning and refusing to prune. Should 3/3 do something else instead? Perhaps prompt for confirmation or require some sort of --force? -- Dennis Kaarsemaker www.kaarsemaker.net -- 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