From: Jeremy Morton <admin@game-point.net>
To: Chris Packham <judge.packham@gmail.com>
Cc: git@vger.kernel.org, mara.kim@vanderbilt.edu, gitster@pobox.com
Subject: Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Date: Mon, 03 Oct 2016 16:36:34 +0100 [thread overview]
Message-ID: <57F27B02.8080803@game-point.net> (raw)
In-Reply-To: <1401874256-13332-1-git-send-email-judge.packham@gmail.com>
Did this ever get anywhere? Can we recursively update submodules with
"git pull" in the supermodule now?
--
Best regards,
Jeremy Morton (Jez)
On 04/06/2014 10:30, Chris Packham wrote:
> Add a config option that will cause clone to recurse into submodules as
> if the --recurse-submodules option had been specified on the command
> line. This can be overridden with the --no-recurse-submodules option.
>
> Signed-off-by: Chris Packham<judge.packham@gmail.com>
> ---
> On 04/06/14 09:05, Junio C Hamano wrote:
>>> Mara Kim<mara.kim@vanderbilt.edu> writes:
>>>
>>>> Apologies if this question has been asked already, but what is the
>>>> reasoning behind making git clone not recursive (--recursive) by
>>>> default?
>>>
>>> The primary reason why submodules are separate repositories is not
>>> to require people to have everything. Some people want recursive,
>>> some others don't, and the world is not always "majority wins" (not
>>> that I am saying that majority will want recursive).
>>>
>>> Inertia, aka backward compatibility and not surprising existing
>>> users, plays some role when deciding the default.
>>>
>>> Also, going --recursive when the user did not want is a lot more
>>> expensive mistake to fix than not being --recursive when the user
>>> wanted to.
>>
>> Having said all that, I do not mean to say that I am opposed to
>> introduce some mechanism to let the users express their preference
>> between recursive and non-recursive better, so that "git clone"
>> without an explicit --recursive (or --no-recursive) can work to
>> their taste. A configuration in $HOME/.gitconfig might be a place
>> to start, even though that has the downside of assuming that the
>> given user would want to use the same settings for all his projects,
>> which may not be the case in practice.
>
> And here's a quick proof of concept. Not sure about the config variable name
> and it could probably do with a negative test as well.
>
> builtin/clone.c | 9 +++++++++
> t/t7407-submodule-foreach.sh | 17 +++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index b12989d..92aea81 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -734,6 +734,14 @@ static void write_refspec_config(const char* src_ref_prefix,
> strbuf_release(&value);
> }
>
> +static int git_clone_config(const char *key, const char *value, void *data)
> +{
> + if (!strcmp(key, "clone.recursesubmodules"))
> + option_recursive = git_config_bool(key, value);
> +
> + return 0;
> +}
> +
> int cmd_clone(int argc, const char **argv, const char *prefix)
> {
> int is_bundle = 0, is_local;
> @@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> junk_pid = getpid();
>
> packet_trace_identity("clone");
> + git_config(git_clone_config, NULL);
> argc = parse_options(argc, argv, prefix, builtin_clone_options,
> builtin_clone_usage, 0);
>
> diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
> index 7ca10b8..fc2c189 100755
> --- a/t/t7407-submodule-foreach.sh
> +++ b/t/t7407-submodule-foreach.sh
> @@ -307,6 +307,23 @@ test_expect_success 'use "update --recursive nested1" to checkout all submodules
> )
> '
>
> +test_expect_success 'use "git clone" with clone.recursesubmodules to checkout all submodules' '
> + git config --local clone.recursesubmodules true&&
> + git clone super clone7&&
> + (
> + cd clone7&&
> + git rev-parse --resolve-git-dir .git&&
> + git rev-parse --resolve-git-dir sub1/.git&&
> + git rev-parse --resolve-git-dir sub2/.git&&
> + git rev-parse --resolve-git-dir sub3/.git&&
> + git rev-parse --resolve-git-dir nested1/.git&&
> + git rev-parse --resolve-git-dir nested1/nested2/.git&&
> + git rev-parse --resolve-git-dir nested1/nested2/nested3/.git&&
> + git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
> + )&&
> + git config --local --unset clone.recursesubmodules
> +'
> +
> test_expect_success 'command passed to foreach retains notion of stdin' '
> (
> cd super&&
next prev parent reply other threads:[~2016-10-03 15:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-03 18:11 Paper cut bug: Why isn't "git clone xxxx" recursive by default? Mara Kim
2014-06-03 19:52 ` Junio C Hamano
2014-06-03 21:05 ` Junio C Hamano
2014-06-03 22:24 ` Mara Kim
2014-06-04 9:30 ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham
2014-06-04 17:24 ` Junio C Hamano
2014-06-04 19:06 ` Jens Lehmann
2014-06-05 18:18 ` Junio C Hamano
2014-06-05 18:43 ` W. Trevor King
2014-06-06 5:26 ` Heiko Voigt
2017-08-02 18:11 ` Jeremy Morton
2017-08-02 20:34 ` Stefan Beller
2014-06-04 19:42 ` Heiko Voigt
2014-06-05 7:48 ` Chris Packham
2014-06-06 5:54 ` Heiko Voigt
2014-06-06 16:35 ` Junio C Hamano
2014-06-09 13:17 ` Jens Lehmann
2014-06-09 23:27 ` W. Trevor King
2016-10-03 15:36 ` Jeremy Morton [this message]
2016-10-03 17:18 ` Stefan Beller
2016-10-04 11:41 ` Heiko Voigt
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=57F27B02.8080803@game-point.net \
--to=admin@game-point.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=judge.packham@gmail.com \
--cc=mara.kim@vanderbilt.edu \
/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.