From: "Carlos Martín Nieto" <cmn@elego.de>
To: git@vger.kernel.org
Subject: [WIP PATCH 0/2] Be more careful when prunning
Date: Thu, 6 Oct 2011 18:56:25 +0200 [thread overview]
Message-ID: <1317920187-17389-1-git-send-email-cmn@elego.de> (raw)
In-Reply-To: <20111004103624.GA11863@sigill.intra.peff.net>
[I turns out that my system was slightly misconfigured, so vger didn't
want to accept my mail, this a re-send to the list only]
Hello,
I consider this WIP because I haven't addressed the issue when --tags
is given. It's likely the most common issue (and what sparked this),
but the second patch sets it up so it becomes easier.
The first patch is not that big a deal, but it's better if we're
freeing the refspecs, we might as well free all of them.
The second patch teaches get_stale_heads to use the user-provided
refspecs instead of the ones in the config. For example, running
git fetch --prune origin refs/heads/master:refs/heads/master
doesn't remove the other branches anymore. For a more interesting (and
believable) example, let's take
git fetch --prune origin refs/heads/b/*:refs/heads/b/*
because you want to prune the refs inside the b/ namespace
only. Currently git will delete all the refs that aren't under that
namespace. With the second patch applied, git won't remove any refs
outside the b/ namespace.
Now comes the interesting part: when --tags is given, there is no
refspec set up, fetch just sets up a global variable. What I'm
thinking (and going to implement after dinner, unless people cry out
against it) is this: just before calling prune_refs, add a refspec to
the user-provided list with the refspec refs/tags/*:refs/tags/*
similar to what fetch_one does if you gave it "tag v1.5.6". This would
cause us to ignore the configured refspec and keep the branches. The
lack of '+' is most certainly on purpose. Is there anything
fundamentally wrong with that idea?
Cheers,
cmn
Carlos Martín Nieto (2):
fetch: free all the additional refspecs
fetch: honor the user-provided refspecs when pruning refs
builtin/fetch.c | 8 +++---
builtin/remote.c | 2 +-
remote.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++-----
remote.h | 3 +-
4 files changed, 74 insertions(+), 13 deletions(-)
--
1.7.5.2.354.g349bf
next prev parent reply other threads:[~2011-10-06 16:56 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
2011-10-06 16:56 ` Carlos Martín Nieto [this message]
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=1317920187-17389-1-git-send-email-cmn@elego.de \
--to=cmn@elego.de \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).