Re: [BUG?] git fetch -p -t prunes all non-tag refs
- From
Jeff King <peff@peff.net>
- Date
- Oct 4, 2011, 10:36 UTC
- Message-ID
- <20111004103624.GA11863@sigill.intra.peff.net>
- In-Reply-To
- <1317724404.2577.6.camel@bee.lab.cmartin.tk>
On Tue, Oct 04, 2011 at 12:33:22PM +0200, Carlos Martín Nieto wrote:
Show 19 quoted lines
> > 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.
Let's not worry about the first one for now, then. It is a natural extension of the other, but in practice, I don't expect people to really care that much about auto-pruning one specific ref. Instead, they want to prune wildcards. So as long as it works in the wildcard case, that is a good start.
Show 7 quoted lines
> > # 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.
I wanted it to auto-prune the remote branches. So if I delete "refs/heads/foo" locally, then it will be deleted from the backup on the next push. Regular "push" will not do that, but --mirror will.
-Peff