All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Claire Fousse <claire.fousse@ensimag.imag.fr>,
	git@vger.kernel.org, Sylvain Boulme <Sylvain.Boulme@imag.fr>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 10/10] clone: accept config options on the command line
Date: Thu, 9 Jun 2011 16:56:19 -0400	[thread overview]
Message-ID: <20110609205619.GC4671@sigill.intra.peff.net> (raw)
In-Reply-To: <20110609171214.GA30888@sigill.intra.peff.net>

On Thu, Jun 09, 2011 at 01:12:14PM -0400, Jeff King wrote:

> > > +-c <key>=<value>::
> > > +       Set a configuration variable in the newly-cloned repository. The
> > 
> > Shouldn't this be 'newly-created repository', because the
> > configuration variables are set before the actual cloning, but after
> > initializing the new repository.
> 
> Yeah, I think your wording is better. It might also make sense to
> explicitly say that the config takes effect during the fetch and
> checkout phases of the clone (there's otherwise no point, of course, but
> it never hurts to make the documentation clear).

There was also an unrelated typo in the newly-added documentation. So
here's a replacement 10/10 with the fixed documentation.

-- >8 --
Subject: [PATCH] clone: accept config options on the command line

Clone does all of init, "remote add", fetch, and checkout
without giving the user a chance to intervene and set any
configuration. This patch allows you to set config options
in the newly created repository after the clone, but before
we do any other operations.

In many cases, this is a minor convenience over something
like:

  git clone git://...
  git config core.whatever true

But in some cases, it can bring extra efficiency by changing
how the fetch or checkout work. For example, setting
line-ending config before the checkout avoids having to
re-checkout all of the contents with the correct line
endings.

It also provides a mechanism for passing information to remote
helpers during a clone; the helpers may read the git config
to influence how they operate.

Signed-off-by: Jeff King <peff@peff.net>
---
 Documentation/git-clone.txt |   11 +++++++++++
 builtin/clone.c             |   21 ++++++++++++++++++++-
 t/t5707-clone-config.sh     |   40 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 71 insertions(+), 1 deletions(-)
 create mode 100755 t/t5707-clone-config.sh

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b093e45..4b8b26b 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -159,6 +159,17 @@ objects from the source repository into a pack in the cloned repository.
 	Specify the directory from which templates will be used;
 	(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
 
+--config <key>=<value>::
+-c <key>=<value>::
+	Set a configuration variable in the newly-created repository;
+	this takes effect immediately after the repository is
+	initialized, but before the remote history is fetched or any
+	files checked out.  The key is in the same format as expected by
+	linkgit:git-config[1] (e.g., `core.eol=true`). If multiple
+	values are given for the same key, each value will be written to
+	the config file. This makes it safe, for example, to add
+	additional fetch refspecs to the origin remote.
+
 --depth <depth>::
 	Create a 'shallow' clone with a history truncated to the
 	specified number of revisions.  A shallow repository has a
diff --git a/builtin/clone.c b/builtin/clone.c
index f579794..a15784a 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -46,6 +46,7 @@ static const char *real_git_dir;
 static char *option_upload_pack = "git-upload-pack";
 static int option_verbosity;
 static int option_progress;
+static struct string_list option_config;
 
 static struct option builtin_clone_options[] = {
 	OPT__VERBOSITY(&option_verbosity),
@@ -83,7 +84,8 @@ static struct option builtin_clone_options[] = {
 		    "create a shallow clone of that depth"),
 	OPT_STRING(0, "separate-git-dir", &real_git_dir, "gitdir",
 		   "separate git dir from working tree"),
-
+	OPT_STRING_LIST('c', "config", &option_config, "key=value",
+			"set config inside the new repository"),
 	OPT_END()
 };
 
@@ -364,6 +366,22 @@ static void write_remote_refs(const struct ref *local_refs)
 	clear_extra_refs();
 }
 
+static int write_one_config(const char *key, const char *value, void *data)
+{
+	return git_config_set_multivar(key, value ? value : "true", "^$", 0);
+}
+
+static void write_config(struct string_list *config)
+{
+	int i;
+
+	for (i = 0; i < config->nr; i++) {
+		if (git_config_parse_parameter(config->items[i].string,
+					       write_one_config, NULL) < 0)
+			die("unable to write parameters to config file");
+	}
+}
+
 int cmd_clone(int argc, const char **argv, const char *prefix)
 {
 	int is_bundle = 0, is_local;
@@ -482,6 +500,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 			printf(_("Cloning into %s...\n"), dir);
 	}
 	init_db(option_template, INIT_DB_QUIET);
+	write_config(&option_config);
 
 	/*
 	 * At this point, the config exists, so we do not need the
diff --git a/t/t5707-clone-config.sh b/t/t5707-clone-config.sh
new file mode 100755
index 0000000..27d730c
--- /dev/null
+++ b/t/t5707-clone-config.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+test_description='tests for git clone -c key=value'
+. ./test-lib.sh
+
+test_expect_success 'clone -c sets config in cloned repo' '
+	rm -rf child &&
+	git clone -c core.foo=bar . child &&
+	echo bar >expect &&
+	git --git-dir=child/.git config core.foo >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success 'clone -c can set multi-keys' '
+	rm -rf child &&
+	git clone -c core.foo=bar -c core.foo=baz . child &&
+	{ echo bar; echo baz; } >expect &&
+	git --git-dir=child/.git config --get-all core.foo >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success 'clone -c without a value is boolean true' '
+	rm -rf child &&
+	git clone -c core.foo . child &&
+	echo true >expect &&
+	git --git-dir=child/.git config --bool core.foo >actual &&
+	test_cmp expect actual
+'
+
+test_expect_success 'clone -c config is available during clone' '
+	echo content >file &&
+	git add file &&
+	git commit -m one &&
+	rm -rf child &&
+	git clone -c core.autocrlf . child &&
+	printf "content\\r\\n" >expect &&
+	test_cmp expect child/file
+'
+
+test_done
-- 
1.7.6.rc1.36.g91167

  reply	other threads:[~2011-06-09 20:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-08 11:19 Git-Mediawiki : cloning a set of pages Claire Fousse
2011-06-08 15:19 ` Jeff King
2011-06-08 17:04   ` Sverre Rabbelier
2011-06-08 17:13     ` Jeff King
2011-06-09 15:50   ` Jeff King
2011-06-09 15:51     ` [PATCH 01/10] strbuf_split: add a max parameter Jeff King
2011-06-13 17:30       ` Junio C Hamano
2011-06-13 19:20         ` Jeff King
2011-06-09 15:51     ` [PATCH 02/10] fix "git -c" parsing of values with equals signs Jeff King
2011-06-09 15:52     ` [PATCH 03/10] config: die on error in command-line config Jeff King
2011-06-09 15:52     ` [PATCH 04/10] config: avoid segfault when parsing " Jeff King
2011-06-13 17:30       ` Junio C Hamano
2011-06-13 19:22         ` Jeff King
2011-06-09 15:54     ` [PATCH 05/10] strbuf: allow strbuf_split to work on non-strbufs Jeff King
2011-06-09 15:55     ` [PATCH 06/10] config: use strbuf_split_str instead of a temporary strbuf Jeff King
2011-06-09 15:55     ` [PATCH 07/10] parse-options: add OPT_STRING_LIST helper Jeff King
2011-06-09 15:55     ` [PATCH 08/10] remote: use new OPT_STRING_LIST Jeff King
2011-06-09 15:56     ` [PATCH 09/10] config: make git_config_parse_parameter a public function Jeff King
2011-06-09 15:57     ` [PATCH 10/10] clone: accept config options on the command line Jeff King
2011-06-09 17:10       ` Bert Wesarg
2011-06-09 17:12         ` Jeff King
2011-06-09 20:56           ` Jeff King [this message]
2011-06-09 22:34       ` Matthieu Moy
2011-06-08 17:14 ` Git-Mediawiki : cloning a set of pages Jakub Narebski
2011-06-09  9:06   ` Claire Fousse

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=20110609205619.GC4671@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=Sylvain.Boulme@imag.fr \
    --cc=bert.wesarg@googlemail.com \
    --cc=claire.fousse@ensimag.imag.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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.