Re: [PATCH] remote: make prune work for mixed mirror/non-mirror repos

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 20, 2013, 23:30 UTC
Message-ID: <7vhagspdfx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1371769636.17896.44.camel@localhost>

Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:

Show 16 quoted lines

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

Show 7 quoted lines

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