git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Carlos Martín Nieto" <cmn@elego.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: mathstuf@gmail.com, git@vger.kernel.org
Subject: Re: [BUG?] git fetch -p -t prunes all non-tag refs
Date: Tue, 27 Sep 2011 01:11:03 +0200	[thread overview]
Message-ID: <1317078667.5579.13.camel@centaur.lab.cmartin.tk> (raw)
In-Reply-To: <7vehz30wdy.fsf@alter.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

On Mon, 2011-09-26 at 15:30 -0700, Junio C Hamano wrote:
> Ben Boeckel <mathstuf@gmail.com> writes:
> 
> > When the --prune and --tags options are given to git fetch together, all
> > non-tag refs are pruned because only tags are looked at and when pruning
> > it appears as if the branches have disappeared and are therefore deleted
> > locally.
> 
> I would call that a bug, and it is not limited to the use of "--tags". For
> example, I suspect that
> 
>     $ git fetch --prune origin refs/heads/master:refs/remotes/origin/master
> 
> would prune remote tracking branches for "origin" other than "master".

This should fix it (in a way). Let's agree that it's a bad idea and
complain to the user. Looking at the surrounding code, I can't find
anything obvious that would break, and `git fetch --prune --multiple a
b` is allowed.

Patch on top of maint.

--- 8< ---
Subject: [PATCH] fetch: disallow --prune in combination with tags or refspecs

Pruning shouldn't be used when other options limit the references that
should be taken into account. For example

    git fetch --prune --tags origin
    git fetch --prune origin refs/heads/*:refs/remotes/*

Both these commands would remove references which do still exist in
the remote.

Print an error and exit if prune is selected at the same time as
either tags are selected or a refspec is given.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
 builtin/fetch.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index e422ced..158b20a 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -967,6 +967,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
 			if (!add_remote_or_group(argv[i], &list))
 				die(_("No such remote or remote group: %s"), argv[i]);
 		result = fetch_multiple(&list);
+	} else if (prune && (argc == 2 || tags != TAGS_DEFAULT)) {
+		/* The if (multiple) is above so we don't report multiple remotes as an error */
+		die(_("Pruning and limiting refs is not compatible"));
 	} else {
 		/* Single remote or group */
 		(void) add_remote_or_group(argv[0], &list);
-- 
1.7.5.2.354.g349bf




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  parent reply	other threads:[~2011-09-26 23:11 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 [this message]
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               ` [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=1317078667.5579.13.camel@centaur.lab.cmartin.tk \
    --to=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 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).