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

Dennis Kaarsemaker [off-list ref] writes:

quoted

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

quoted

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.

On do, 2013-06-20 at 16:30 -0700, Junio C Hamano wrote:

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

Yes, I misunderstood you and see the problem now. Thanks for being
patient with me :)

quoted

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.

quoted

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.

I'm halfway through cooking up a patch for B, as I agree that it will
make things safer.

I'd really like to have C as well though, would you accept a patch that
implements it?
-- 
Dennis Kaarsemaker
www.kaarsemaker.net