git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Carlos Martín NietoNext: Carlos Martín Nieto
Message 9 of 14 in “[BUG?] git fetch -p -t prunes all non-tag refs”
  1. Ben BoeckelSep 26, 2011
  2. Junio C HamanoSep 26, 2011
  3. Ben BoeckelSep 26, 2011
  4. Carlos Martín NietoSep 26, 2011
  5. Junio C HamanoSep 26, 2011
  6. Carlos Martín NietoSep 26, 2011
  7. Jeff KingSep 27, 2011
  8. Carlos Martín NietoOct 4, 2011
  9. Jeff KingOct 4, 2011
  10. Carlos Martín NietoOct 4, 2011
  11. 0/2 Be more careful when prunningCarlos Martín Nieto, Oct 6, 2011
  12. 1/2 fetch: free all the additional refspecsCarlos Martín Nieto, Oct 6, 2011
  13. 2/2 fetch: honor the user-provided refspecs when pruning refsCarlos Martín Nieto, Oct 6, 2011
  14. Junio C HamanoOct 7, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.