All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Carlos Martín Nieto" <cmn@elego.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	mathstuf@gmail.com, git@vger.kernel.org
Subject: Re: [BUG?] git fetch -p -t prunes all non-tag refs
Date: Tue, 4 Oct 2011 06:36:24 -0400	[thread overview]
Message-ID: <20111004103624.GA11863@sigill.intra.peff.net> (raw)
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:

> > 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.

> >       # 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

  reply	other threads:[~2011-10-04 10:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-26 18:47 [BUG?] git fetch -p -t prunes all non-tag refs Ben Boeckel
2011-09-26 22:30 ` Junio C Hamano
2011-09-26 22:51   ` Ben Boeckel
2011-09-26 23:11   ` Carlos Martín Nieto
2011-09-26 23:16     ` Junio C Hamano
2011-09-26 23:28       ` Carlos Martín Nieto
2011-09-27  3:31         ` Jeff King
2011-10-04 10:33           ` Carlos Martín Nieto
2011-10-04 10:36             ` Jeff King [this message]
2011-10-04 11:06               ` Carlos Martín Nieto
2011-10-06 16:56               ` [WIP PATCH 0/2] Be more careful when prunning Carlos Martín Nieto
2011-10-06 16:56                 ` [PATCH 1/2] fetch: free all the additional refspecs Carlos Martín Nieto
2011-10-06 16:56                 ` [PATCH 2/2] fetch: honor the user-provided refspecs when pruning refs Carlos Martín Nieto
2011-10-07 23:00                 ` [WIP PATCH 0/2] Be more careful when prunning Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111004103624.GA11863@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mathstuf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.