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

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

[Björn Gustavsson]

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(-)

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

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

[Jay Soffian]

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.

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

[Jeff King]

On Sun, Nov 08, 2009 at 07:59:46PM -0500, Jay Soffian wrote:

> 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

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

[Björn Gustavsson]

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