Skip to contentSkip to conversation

Teach the --multiple option to 'git fetch'

PATCH In review Björn Gustavsson 3 participants 4 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 2/4 Teach the --multiple option to 'git fetch'

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.

---
 builtin-fetch.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)
builtin-fetch.c +9 -1
index a520c1b..7926658 100644
@@ -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);
Signature · 1 line
1.6.5.1.69.g36942
#1 lore raw

2009/11/8 Björn Gustavsson <[email protected]>:

Quoted 3 lines

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.

#2 lore raw
Quoted 11 lines · Jay Soffian

2009/11/8 Björn Gustavsson <[email protected]>:

Quoted 3 lines

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

#3 lore raw

2009/11/9 Jeff King <[email protected]>:

Quoted 2 lines

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.

Signature · 1 line
Björn Gustavsson, Erlang/OTP, Ericsson AB