Dennis Kaarsemaker <dennis@xxxxxxxxxxxxxxx> writes: >> Going back to your original example: >> >> [remote "origin"] >> url = git://github.com/git/git.git >> fetch = +refs/*:refs/* >> mirror = true >> [remote "peff"] >> url = git://github.com/peff/git.git >> fetch = +refs/heads/*:refs/remotes/peff/* >> >> Wouldn't you obtain "refs/remotes/github/html" from your "origin" >> via "git pull origin"? What happens to your local copy of that ref, >> when it goes away from the origin and then you try to "fetch --prune >> origin" the next time with this patch (and without this patch)? > > git pull origin gives me refs/html in this case. Maybe there is a miscommunication. $ git ls-remote git://github.com/git/git.git | grep remotes/ shows that that repository, your origin, has refs/remotes/github/html And you have remote.origin.fetch = +refs/*:refs/* in your local repository. So that ref will come to your local repository under the same name, i.e. refs/remotes/github/html, no? Not as refs/html. So this answer >> What if you had this instead of the above version of remote.peff.*? >> >> [remote "peff"] >> url = git://github.com/peff/git.git >> fetch = +refs/heads/*:refs/remotes/github/* > > That doesn't change anything. cannot be correct. You fetch from your origin and then its refs/remotes/github/html *will* want to come to your local repository and be stored there. If Peff has html branch in that hypothetical configuration, you fetch from him and his html branch (i.e. refs/heads/html from his point of view) will want to replace your local refs/remotes/github/html. Or Peff may not have html branch. The point is that you cannot tell by only looking at your local ref namespace and what "origin" has. > Yeah, I'm starting to think this is not such a good idea. How about plan > B: issuing a warning when adding a remote with a refspec that also > matches another remote's refspec? Surely that will make things safer. > Or plan C: add a per-remote pruneIgnore setting that in this case I > could set to refs/tags/* refs/remotes/* as I know it's correct? Could > even be combined with plan B. As I already said "I dunno", I am not sure if it is worth the effort to support overlapping RHSs of fetch refspecs, so between B and C, I would vote for B. -- 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