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

From: Carlos Martín Nieto <cmn@elego.de>
Date: Oct 4, 2011, 10:33 UTC
Message-ID: <1317724404.2577.6.camel@bee.lab.cmartin.tk>
In-Reply-To: <20110927033134.GB8534@sigill.intra.peff.net>

On Mon, 2011-09-26 at 23:31 -0400, Jeff King wrote:

Show 22 quoted lines

> On Tue, Sep 27, 2011 at 01:28:09AM +0200, Carlos Martín Nieto wrote:
> 
> > > 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?
> 
> The latter. If I say:
> 
>   git fetch --prune origin refs/heads/master:refs/remotes/origin/master
> 
> and refs/heads/master doesn't exist on the remote, I would expect
> refs/remotes/origin/master to be deleted locally. And that naturally
> extends to:
> 
>   git fetch --prune origin refs/heads/*:refs/remotes/origin/*

I have some code locally that solves this second part. If we are given refspecs on the command-line, it will try to match against that instead of blindly trusting what get_stale_heads tells us. I'm looking into putting the logic into get_stale_heads so that we can trust it.

The first part might be more complicated. If the remote head doesn't exist, get_fetch_map dies. It does take a missing_ok flag, so it might be as easy as passing 1 there; but I'm not sure what that would do for a non-prune fetch.

Show 14 quoted lines

> 
> We do something similar with "git push --mirror", which does pruning
> like this[1].
> 
> -Peff
> 
> [1] Actually, I'm not sure how correct "push --mirror" is. It would be
>     nice if the prune operation could be split from the mirror, too. In
>     the past, I have wanted to do both:
> 
>       # backup to a repository where our objects will be shared
>       # with other related backups. So we must only use our slice of the
>       # ref namespace.
>       git push --mirror backup-repo +refs/*:refs/`hostname`/*

Is --mirror needed there? I would have thought that refs/*:refs/`hostname`/* would do the same by itself.

Show 14 quoted lines

> 
>     and:
> 
>       # update topic branches we have already published (using the
>       # "matching" refspec), but remove any that we have deleted
>       # locally.
>       git push --mirror publish-point +:
> 
>     and I don't think either works.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>