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
Carlos Martín Nieto <cmn@elego.de>
Date
Oct 4, 2011, 11:06 UTC
Message-ID
<1317726379.2577.19.camel@bee.lab.cmartin.tk>
In-Reply-To
<20111004103624.GA11863@sigill.intra.peff.net>
On Tue, 2011-10-04 at 06:36 -0400, Jeff King wrote:
Show 27 quoted lines
> On Tue, Oct 04, 2011 at 12:33:22PM +0200, Carlos Martín Nieto wrote:
> 
> > > 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.

I'm going to add the logic to do specific-ref-prunning because it's just adding a strcmp to an if (I may yet be proven wrong, mind) and if that works, we can use it later. get_stale_heads is going to gain a couple of arguments so it can inspect the user-given refspecs. It should now be a simple matter of adding a check to see if the refspec's dst matches the refname (it's a simple matter once you've spent five hours trying to understand what the fetch code does).

Show 12 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.
OK, gotcha.
   cmn
Previous: Jeff KingNext: Carlos Martín Nieto
Message 10 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.