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. 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. -- 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