threads / rfc / 21535

RFC patch, 4 partsTeach the --multiple option to 'git fetch'

Subject: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'

## tl;dr

4 messages between Nov 8, 2009 and Nov 9, 2009. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Björn Gustavsson· Nov 8, 2009, 15:46 UTC · lore

Add the --multiple option to specify that all arguments are either groups or remotes. The primary reason for adding this option is to allow us to re-implement 'git remote update' using fetch.

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
 builtin-fetch.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)
Show changes to builtin-fetch.c +9 −1
diff --git a/builtin-fetch.c b/builtin-fetch.c
index a520c1b..7926658 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -24,7 +24,7 @@ enum {
 	TAGS_SET = 2
 };
 
-static int all, append, force, keep, update_head_ok, verbosity;
+static int all, append, force, keep, multiple, update_head_ok, verbosity;
 static int tags = TAGS_DEFAULT;
 static const char *depth;
 static const char *upload_pack;
@@ -41,6 +41,8 @@ static struct option builtin_fetch_options[] = {
 		   "path to upload pack on remote end"),
 	OPT_BOOLEAN('f', "force", &force,
 		    "force overwrite of local branch"),
+	OPT_BOOLEAN('m', "multiple", &multiple,
+		    "fetch from multiple remotes"),
 	OPT_SET_INT('t', "tags", &tags,
 		    "fetch all tags and associated objects", TAGS_SET),
 	OPT_SET_INT('n', NULL, &tags,
@@ -838,6 +840,12 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
 		/* No arguments -- use default remote */
 		remote = remote_get(NULL);
 		result = fetch_one(remote, argc, argv);
+	} else if (multiple) {
+		/* All arguments are assumed to be remotes or groups */
+		for (i = 0; i < argc; i++)
+			if (!add_remote_or_group(argv[i], &list))
+				die("No such remote or remote group: %s", argv[i]);
+		result = fetch_multiple(&list);
 	} else {
 		/* Single remote or group */
 		(void) add_remote_or_group(argv[0], &list);
-- 
1.6.5.1.69.g36942
Jay Soffian· Nov 9, 2009, 00:59 UTC · re: Björn Gustavsson · lore

Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'

2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
> Add the --multiple option to specify that all arguments are either
> groups or remotes. The primary reason for adding this option is
> to allow us to re-implement 'git remote update' using fetch.

Can't this be determined automagically by inspecting the arguments? I believe there can be two unambiguous usages:

a) git fetch <repository> <refspec>... b) git fetch <repository>...

If there is more than one argument, either:

a) arguments 2...N must be refpecs (i.e., each must contain a colon) b) arguments 2...N must NOT be refspecs

"The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>."

j.
Jeff King· Nov 9, 2009, 01:08 UTC · re: Jay Soffian · lore

Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'

On Sun, Nov 08, 2009 at 07:59:46PM -0500, Jay Soffian wrote:
Show 11 quoted lines
> 2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
> > Add the --multiple option to specify that all arguments are either
> > groups or remotes. The primary reason for adding this option is
> > to allow us to re-implement 'git remote update' using fetch.
> 
> Can't this be determined automagically by inspecting the arguments? I
> believe there can be two unambiguous usages:
> [...]
> "The format of a <refspec> parameter is an optional plus +, followed
> by the source ref <src>, followed by a colon :, followed by the
> destination ref <dst>."

Isn't the colon optional, indicating that the ref should be fetched into FETCH_HEAD? I.e.,

  $ git fetch origin pu
  From git://git2.kernel.org/pub/scm/git/git
   * branch            pu         -> FETCH_HEAD
?
-Peff
Björn Gustavsson· Nov 9, 2009, 06:25 UTC · re: Jeff King · lore

Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'

2009/11/9 Jeff King <peff@peff.net>:
> Isn't the colon optional, indicating that the ref should be fetched into
> FETCH_HEAD?
Yes, that's why I was forced to invent a new option.
-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB

← back to recent threads