Re: [BUG?] git fetch -p -t prunes all non-tag refs

From: Carlos Martín Nieto <cmn@elego.de>
Date: Sep 26, 2011, 23:28 UTC
Message-ID: <1317079692.5579.19.camel@centaur.lab.cmartin.tk>
In-Reply-To: <7v1uv228t4.fsf@alter.siamese.dyndns.org>

On Mon, 2011-09-26 at 16:16 -0700, Junio C Hamano wrote:

Show 21 quoted lines

> Carlos Martín Nieto <cmn@elego.de> writes:
> 
> > On Mon, 2011-09-26 at 15:30 -0700, Junio C Hamano wrote:
> >> Ben Boeckel <mathstuf@gmail.com> writes:
> >> 
> >> > When the --prune and --tags options are given to git fetch together, all
> >> > non-tag refs are pruned because only tags are looked at and when pruning
> >> > it appears as if the branches have disappeared and are therefore deleted
> >> > locally.
> >> 
> >> I would call that a bug, and it is not limited to the use of "--tags". For
> >> example, I suspect that
> >> 
> >>     $ git fetch --prune origin refs/heads/master:refs/remotes/origin/master
> >> 
> >> would prune remote tracking branches for "origin" other than "master".
> >
> > This should fix it (in a way). Let's agree that it's a bad idea and
> > complain to the user.
> 
> That might be a reasonable short-term safety measure, but in the longer

Sure.

Show 5 quoted lines

> term I think we should fix it properly. We are already learning "what are
> the refs the remote side currently has" from the transport and the right
> fix ought to be to use that original information, not the version filtered
> for the use of the primary objective of fetch, which is to only fetch what
> the user asked for.

Do you mean that we should ignore the refspec? Or do you mean that we should look at the refspec if it exists, and only consider deleting those that meet the refspec, so that `--prune --tags` would only delete tags that don't exist in the remote?

Either way, it's a bit more complicated than a two-liner and it's too late in my timezone for that. I'll try to see if I can do it in the next few days.

cmn