From: "Carlos Martín Nieto" <cmn@elego.de>
To: Jeff King <peff@peff.net>
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, 04 Oct 2011 13:06:18 +0200 [thread overview]
Message-ID: <1317726379.2577.19.camel@bee.lab.cmartin.tk> (raw)
In-Reply-To: <20111004103624.GA11863@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]
On Tue, 2011-10-04 at 06:36 -0400, Jeff King wrote:
> 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).
>
> > > # 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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2011-10-04 11:06 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
2011-10-04 11:06 ` Carlos Martín Nieto [this message]
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=1317726379.2577.19.camel@bee.lab.cmartin.tk \
--to=cmn@elego.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mathstuf@gmail.com \
--cc=peff@peff.net \
/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.