From: Dan Johnson <computerdruid@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Oswald Buddenhagen <ossi@kde.org>,
Dan Johnson <ComputerDruid@gmail.com>
Subject: [PATCHv2] fetch --all: pass --tags/--no-tags through to each remote
Date: Wed, 5 Sep 2012 17:22:19 -0400 [thread overview]
Message-ID: <1346880139-2281-1-git-send-email-ComputerDruid@gmail.com> (raw)
In-Reply-To: <20120901112251.GA11445@sigill.intra.peff.net>
When fetch is invoked with --all, we need to pass the tag-following
preference to each individual fetch; without this, we will always
auto-follow tags, preventing us from fetching the remote tags into a
remote-specific namespace, for example.
Reported-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Dan Johnson <ComputerDruid@gmail.com>
---
On Sat, Sep 1, 2012 at 7:22 AM, Jeff King <peff@peff.net> wrote:
>Hmm. We allocate argv in fetch_multiple like this:
>
> const char *argv[12] = { "fetch", "--append" };
>
>and then add a bunch of options to it, along with the name of the
>remote. By my count, the current code can hit exactly 12 (including the
>terminating NULL) if all options are set. Your patch would make it
>possible to overflow. Of course, I may be miscounting since it is
>extremely error-prone to figure out the right number by tracing each
>possible conditional.
>
>Maybe we should switch it to a dynamic argv_array? Like this:
>
> [1/2]: argv-array: add pop function
> [2/2]: fetch: use argv_array instead of hand-building arrays
This version is re-rolled to be on top of jk/argv-array, avoiding the issue of
the fixed-size array entirely. If needed, we could of course use the old
version of this patch and bump the number, but I figure this is preferable.
I've also added some test cases to cover this behavior, but I'm not entirely
happy with them. I'm not sure if/how we should be testing the pass-through
behavior of various arguments with fetch --all, but if so, we should probably do
so more thouroughly than I have here, but that just seems like combining
together tests of two unrelated things. It might just make more sense to ignore
it and drop these tests, I don't know.
Sorry this took me a few days to send, I just kept not getting around to it.
builtin/fetch.c | 4 ++++
t/t5514-fetch-multiple.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 6196e91..4494aed 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -858,6 +858,10 @@ static void add_options_to_argv(struct argv_array *argv)
argv_array_push(argv, "--recurse-submodules");
else if (recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND)
argv_array_push(argv, "--recurse-submodules=on-demand");
+ if (tags == TAGS_SET)
+ argv_array_push(argv, "--tags");
+ else if (tags == TAGS_UNSET)
+ argv_array_push(argv, "--no-tags");
if (verbosity >= 2)
argv_array_push(argv, "-v");
if (verbosity >= 1)
diff --git a/t/t5514-fetch-multiple.sh b/t/t5514-fetch-multiple.sh
index 227dd56..cbd2460 100755
--- a/t/t5514-fetch-multiple.sh
+++ b/t/t5514-fetch-multiple.sh
@@ -151,4 +151,33 @@ test_expect_success 'git fetch --multiple (ignoring skipFetchAll)' '
test_cmp ../expect output)
'
+cat > expect << EOF
+EOF
+
+test_expect_success 'git fetch --all --no-tags' '
+ (git clone one test5 &&
+ git clone test5 test6 &&
+ (cd test5 && git tag test-tag) &&
+ cd test6 &&
+ git fetch --all --no-tags &&
+ git tag >output &&
+ test_cmp ../expect output)
+'
+
+cat > expect << EOF
+test-tag
+EOF
+
+test_expect_success 'git fetch --all --tags' '
+ (git clone one test7 &&
+ git clone test7 test8 &&
+ (cd test7 &&
+ test_commit test-tag &&
+ git reset --hard HEAD^) &&
+ cd test8 &&
+ git fetch --all --tags &&
+ git tag >output &&
+ test_cmp ../expect output)
+'
+
test_done
--
1.7.11.1
next prev parent reply other threads:[~2012-09-05 21:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-05 4:56 Bringing a bit more sanity to $GIT_DIR/objects/info/alternates? Junio C Hamano
2012-08-05 9:38 ` Michael Haggerty
2012-08-05 19:01 ` Junio C Hamano
2012-08-07 6:16 ` Jeff King
2012-08-06 21:55 ` Junio C Hamano
2012-08-08 1:42 ` Sascha Cunz
2012-08-11 9:35 ` Hallvard Breien Furuseth
2012-08-27 22:39 ` Oswald Buddenhagen
2012-08-28 19:19 ` GC of alternate object store (was: Bringing a bit more sanity to $GIT_DIR/objects/info/alternates?) Hallvard Breien Furuseth
2012-08-29 7:42 ` Oswald Buddenhagen
2012-08-29 15:52 ` GC of alternate object store Junio C Hamano
2012-08-30 9:53 ` Oswald Buddenhagen
2012-08-30 16:03 ` Junio C Hamano
2012-08-31 16:26 ` Oswald Buddenhagen
2012-08-31 19:18 ` Dan Johnson
2012-08-31 19:45 ` Junio C Hamano
2012-09-01 4:25 ` [PATCH] fetch --all: pass --tags/--no-tags through to each remote Dan Johnson
2012-09-01 11:22 ` Jeff King
2012-09-01 11:25 ` [PATCH 1/2] argv-array: add pop function Jeff King
2012-09-01 11:27 ` [PATCH 2/2] fetch: use argv_array instead of hand-building arrays Jeff King
2012-09-01 14:34 ` Jens Lehmann
2012-09-01 15:27 ` [PATCH] submodule: " Jens Lehmann
2012-09-01 11:32 ` [PATCH] fetch --all: pass --tags/--no-tags through to each remote Jeff King
2012-09-01 11:34 ` [PATCH 3/2] argv-array: fix bogus cast when freeing array Jeff King
2012-09-05 21:22 ` Dan Johnson [this message]
2012-09-07 17:07 ` [PATCHv2] fetch --all: pass --tags/--no-tags through to each remote 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=1346880139-2281-1-git-send-email-ComputerDruid@gmail.com \
--to=computerdruid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ossi@kde.org \
--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.