Dennis Kaarsemaker <den...@kaarsemaker.net> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
