Paper cut bug: Why isn't "git clone xxxx" recursive by default?

Paper cut bug: Why isn't "git clone xxxx" recursive by default?

[Mara Kim]

Hello git devs!

I'd like to start off by saying that git is an amazing piece of
software and every one of you deserve major kudos for your work on the
project.  However, I'd like to point out a few "paper cut" bugs (to
use the Ubuntu parlance).

Apologies if this question has been asked already, but what is the
reasoning behind making git clone not recursive (--recursive) by
default?  I have just recently started splitting my projects into
submodules, and I feel like this is a major usability issue,
especially for newbies.  Wouldn't it be better to have a
"--non-recursive" option and clone recursively by default?  Similarly,
I feel that "git pull" should automatically "git submodule update
--recursive --init" as well, with the current behavior able to be
specified with a "--non-recursive" option.

I feel like these sorts of choices make submodules seem very much like
second class citizens in git and make git much less user friendly.  I
feel that the most common use case that people want is to keep
submodules properly in sync.  In addition, I feel that power users
that really want to make shallow clones, non-recursive clones, etc.
could still be served with a simple option.  I guess there are
problems with changes in submodules being overwritten, so I suppose
there would need to be additional warnings or even just refusal to
pull into dirty directories, similar to the way git behaves in a
regular repository.

Thanks for the excellent work,
Mara Kim

Ph.D. Candidate
Computational Biology
Vanderbilt University
Nashville, TN

Re: Paper cut bug: Why isn't "git clone xxxx" recursive by default?

[Junio C Hamano]

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.

Re: Paper cut bug: Why isn't "git clone xxxx" recursive by default?

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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.

Re: Paper cut bug: Why isn't "git clone xxxx" recursive by default?

[Mara Kim]

That is good to hear.  I would be pretty happy about that. ^.^

Obviously any major changes will need to be done carefully.  I was
thinking of the way that you guys introduced new defaults for Git 2.0,
phasing them in slowly through the 1.x cycle.  Maybe I can get my
hopes up for Git 3.0 --- 9 years from now :P

On Tue, Jun 3, 2014 at 4:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.
>



-- 
Mara Kim

Ph.D. Candidate
Computational Biology
Vanderbilt University
Nashville, TN

[RFC PATCH] clone: add clone.recursesubmodules config option

[Chris Packham]

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 &&
-- 
2.0.0.153.g79dcccc

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Junio C Hamano]

Chris Packham <judge.packham@gmail.com> writes:

> On 04/06/14 09:05, Junio C Hamano wrote:
>>> 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.

I would be more worried about the semantics than the name, though;
re-read the part you quoted with extra stress on "has the downside".

I think I heard the submodule folks (cc'ed) discuss an approach to
allow various submodules to be marked with "tags" with a new type of
entry in .gitmodules file in the superproject, and use these tags to
signal "by default, a new clone will recurse into this submodule".

E.g. if projects standardized on "defaultClone" to mark such
submodules, then $HOME/.gitconfig could say

    [clone]
        recursesubmodules = defaultClone

Or the projects may mark platform specific submodules with tags,
e.g. a .gitmodules in a typical superproject might say something
like this:

    [submodule "posix"]
    	path = ports/posix
        tags = linux obsd fbsd osx
    [submodule "windows"]
        path = ports/windows
        tags = win32
    [submodule "doc"]
    	path = documentation
        tags = defaultClone

and then the user's $HOME/.gitconfig might say

    [clone]
        recursesubmodules = defaultClone win32

to tell a "git clone" of such a superproject to clone the top-level,
read its .gitmodules, and choose documentation/ and ports/windows
submodules but not ports/posix submodule to be further cloned into
the working tree of the superproject.

Of course, if this kind of project organization proves to be useful,
we should try to standardize the set of tags early before people
start coming up with random variations of the same thing, spelling
the same concept in different ways only to be different, and if that
happens, then we could even give a non-empty default value for the
clone.recursesubmodules when $HOME/.gitconfig is missing one.

Just a random thought.

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Jens Lehmann]

Am 04.06.2014 19:24, schrieb Junio C Hamano:
> Chris Packham <judge.packham@gmail.com> writes:
> 
>> On 04/06/14 09:05, Junio C Hamano wrote:
>>>> 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.
> 
> I would be more worried about the semantics than the name, though;
> re-read the part you quoted with extra stress on "has the downside".
> 
> I think I heard the submodule folks (cc'ed) discuss an approach to
> allow various submodules to be marked with "tags" with a new type of
> entry in .gitmodules file in the superproject, and use these tags to
> signal "by default, a new clone will recurse into this submodule".
> 
> E.g. if projects standardized on "defaultClone" to mark such
> submodules, then $HOME/.gitconfig could say
> 
>     [clone]
>         recursesubmodules = defaultClone
> 
> Or the projects may mark platform specific submodules with tags,
> e.g. a .gitmodules in a typical superproject might say something
> like this:
> 
>     [submodule "posix"]
>     	path = ports/posix
>         tags = linux obsd fbsd osx
>     [submodule "windows"]
>         path = ports/windows
>         tags = win32
>     [submodule "doc"]
>     	path = documentation
>         tags = defaultClone
> 
> and then the user's $HOME/.gitconfig might say
> 
>     [clone]
>         recursesubmodules = defaultClone win32
> 
> to tell a "git clone" of such a superproject to clone the top-level,
> read its .gitmodules, and choose documentation/ and ports/windows
> submodules but not ports/posix submodule to be further cloned into
> the working tree of the superproject.
> 
> Of course, if this kind of project organization proves to be useful,
> we should try to standardize the set of tags early before people
> start coming up with random variations of the same thing, spelling
> the same concept in different ways only to be different, and if that
> happens, then we could even give a non-empty default value for the
> clone.recursesubmodules when $HOME/.gitconfig is missing one.

Yes, but maybe we can define how the user wants to set the global or
per-repo default (that is honored as long as upstream or local
config doesn't provide more specific settings, e.g. via tags) and
implement that for clone as a first step, even when we do not now
how e.g. the tags setting might look like in the end. I believe we
should have one or two switches telling Git "I want my submodules be
updated without having to use the 'git submodule' command". And
after that submodule specific overrides can kick in, e.g. when
"submodule.<name>.update" is set to "none" the submodule won't be
updated no matter how the default is.

We had two settings in mind, first "submodule.autoinit" (which would
automate the "git submodule --init" step and also control that a
new submodule is fetched into .git/modules; it'd be fetched there
soon as the fetch in the superproject sees a commit introducing it).
That would kick in on clone, fetch and pull, as the underlying fetch
honors it. And the "submodule.autoupdate" setting which will make
running "git submodule update" obsolete by updating all init'ed
submodules on each clone, checkout, merge, reset etc.. Together
they'd achieve for all relevant commands what Chris' proposed option
would only do for clone.

So what if clone would just do an "git submodule init" for now when
"submodule.autoinit" is set but "submodule.autoupdate" isn't (and as
soon as fetch learns to honor autoinit we could remove that one
again). And if both are set it'd do a "git submodule update --init
--recursive", just like it does when the --recurse-submodules option
is used. As soon as we also have recursive submodule update, we could
remove the latter from clone.

But maybe we are to close to the implementation side of things (where
fetch and checkout just like init and update are two separate things)
and a single "submodule.auto" setting would be what users really want?

Comments welcome.

Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Heiko Voigt]

On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:
> Chris Packham <judge.packham@gmail.com> writes:
> 
> > On 04/06/14 09:05, Junio C Hamano wrote:
> >>> 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.
> 
> I would be more worried about the semantics than the name, though;
> re-read the part you quoted with extra stress on "has the downside".
> 
> I think I heard the submodule folks (cc'ed) discuss an approach to
> allow various submodules to be marked with "tags" with a new type of
> entry in .gitmodules file in the superproject, and use these tags to
> signal "by default, a new clone will recurse into this submodule".
> 
> E.g. if projects standardized on "defaultClone" to mark such
> submodules, then $HOME/.gitconfig could say
> 
>     [clone]
>         recursesubmodules = defaultClone
> 
> Or the projects may mark platform specific submodules with tags,
> e.g. a .gitmodules in a typical superproject might say something
> like this:
> 
>     [submodule "posix"]
>     	path = ports/posix
>         tags = linux obsd fbsd osx
>     [submodule "windows"]
>         path = ports/windows
>         tags = win32
>     [submodule "doc"]
>     	path = documentation
>         tags = defaultClone
> 
> and then the user's $HOME/.gitconfig might say
> 
>     [clone]
>         recursesubmodules = defaultClone win32
> 
> to tell a "git clone" of such a superproject to clone the top-level,
> read its .gitmodules, and choose documentation/ and ports/windows
> submodules but not ports/posix submodule to be further cloned into
> the working tree of the superproject.
> 
> Of course, if this kind of project organization proves to be useful,
> we should try to standardize the set of tags early before people
> start coming up with random variations of the same thing, spelling
> the same concept in different ways only to be different, and if that
> happens, then we could even give a non-empty default value for the
> clone.recursesubmodules when $HOME/.gitconfig is missing one.
> 
> Just a random thought.

I like this idea of specifying different "views" by giving tags. But
does it rule out a boolean clone.recursesubmodules? For the simple case
some people might not want to worry about specifying tags but just want
to configure: "Yes give me everything". So if we were to do this I would
like it if we could have both. Also because the option for clone is
--recurse-submodules and our typical schema is that a configuration
option is named similar so clone.recursesubmodules would fit here.

So either we do this "magically" and all valid boolean values are
forbidden as tags or we would need a different config option. Further
thinking about it: Maybe a general option that does not only apply to
clone would suit the "views" use-case more. E.g. "submodule.tags" or
similar.

Also please note: We have been talking about adding two configurations
for submodules:

	submodule."name".autoclone (IIRC)

I am not sure whether that was the correct name, but this option should
tell recursive fetch / clone whether to automatically clone a submodule
when it appears on a fetch in the history.

	submodule."name".autoinit

And this one is for recursive checkout and tells whether an appearing
submodule should automatically be initialized.

These options fullfill a similar use-case and are planned for the future
when recursive fetch/clone and checkout are in place (which is not that
far away). We might need to rethink these to incoporate the "views from
tags" idea nicely and since we do not want a configuration nightmare.

Cheers Heiko

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Chris Packham]

On 05/06/14 07:42, Heiko Voigt wrote:
> On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:
>> Chris Packham <judge.packham@gmail.com> writes:
>>
>>> On 04/06/14 09:05, Junio C Hamano wrote:
>>>>> 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.
>>
>> I would be more worried about the semantics than the name, though;
>> re-read the part you quoted with extra stress on "has the downside".
>>
>> I think I heard the submodule folks (cc'ed) discuss an approach to
>> allow various submodules to be marked with "tags" with a new type of
>> entry in .gitmodules file in the superproject, and use these tags to
>> signal "by default, a new clone will recurse into this submodule".
>>
>> E.g. if projects standardized on "defaultClone" to mark such
>> submodules, then $HOME/.gitconfig could say
>>
>>     [clone]
>>         recursesubmodules = defaultClone
>>
>> Or the projects may mark platform specific submodules with tags,
>> e.g. a .gitmodules in a typical superproject might say something
>> like this:
>>
>>     [submodule "posix"]
>>     	path = ports/posix
>>         tags = linux obsd fbsd osx
>>     [submodule "windows"]
>>         path = ports/windows
>>         tags = win32
>>     [submodule "doc"]
>>     	path = documentation
>>         tags = defaultClone
>>
>> and then the user's $HOME/.gitconfig might say
>>
>>     [clone]
>>         recursesubmodules = defaultClone win32
>>
>> to tell a "git clone" of such a superproject to clone the top-level,
>> read its .gitmodules, and choose documentation/ and ports/windows
>> submodules but not ports/posix submodule to be further cloned into
>> the working tree of the superproject.
>>
>> Of course, if this kind of project organization proves to be useful,
>> we should try to standardize the set of tags early before people
>> start coming up with random variations of the same thing, spelling
>> the same concept in different ways only to be different, and if that
>> happens, then we could even give a non-empty default value for the
>> clone.recursesubmodules when $HOME/.gitconfig is missing one.
>>
>> Just a random thought.
> 
> I like this idea of specifying different "views" by giving tags. But
> does it rule out a boolean clone.recursesubmodules? For the simple case
> some people might not want to worry about specifying tags but just want
> to configure: "Yes give me everything". So if we were to do this I would
> like it if we could have both. Also because the option for clone is
> --recurse-submodules and our typical schema is that a configuration
> option is named similar so clone.recursesubmodules would fit here.

Maybe using a glob pattern would work.

The user might say

     [clone]
         recursesubmodules = x86*

And .gitmodules might say

     [submodule "foo"]
         tags = x86_64
     [submodule "bar"]
         tags = x86
     [submodule "frotz"]
         tags = powerpc

For the "Yes give me everything" case the user could say

     [clone]
         recursesubmodules = *

> 
> So either we do this "magically" and all valid boolean values are
> forbidden as tags or we would need a different config option. Further
> thinking about it: Maybe a general option that does not only apply to
> clone would suit the "views" use-case more. E.g. "submodule.tags" or
> similar.
> 
> Also please note: We have been talking about adding two configurations
> for submodules:
> 
> 	submodule."name".autoclone (IIRC)
> 
> I am not sure whether that was the correct name, but this option should
> tell recursive fetch / clone whether to automatically clone a submodule
> when it appears on a fetch in the history.
> 
> 	submodule."name".autoinit
> 
> And this one is for recursive checkout and tells whether an appearing
> submodule should automatically be initialized.
> 
> These options fullfill a similar use-case and are planned for the future
> when recursive fetch/clone and checkout are in place (which is not that
> far away). We might need to rethink these to incoporate the "views from
> tags" idea nicely and since we do not want a configuration nightmare.
> 
> Cheers Heiko
> 

I'm a little confused at how autoclone and autoinit differ. Aren't they
the same? i.e. when this module appears grab it by default. I see
autoupdate as a little different meaning update it if it's been
initialised. Also does autoinit imply autoupdate?

At $dayjob we have a superproject which devs clone this has submodules
for the important and/or high touch repositories. We have other
repositories that are normally build from a tarball (or not built at
all) but we can build them from external repositories if needed. The
latter case is painfully manual. If autoinit/autoupdate existed we'd
probably setup out projects with.

    [submodule "linux"]
        autoinit = true
	autoupdate = true
    [submodule "userland"]
        autoinit = true
	autoupdate = true
    [submodule "not-used-that-much"]
	autoupdate = true

We probably wouldn't make use of tags because we're building complete
embedded systems and generally want everything, even if we are doing
most of our work on a particular target we need to do builds for other
targets for sanity checks.

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Junio C Hamano]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> ... I believe we
> should have one or two switches telling Git "I want my submodules be
> updated without having to use the 'git submodule' command". And
> after that submodule specific overrides can kick in, e.g. when
> "submodule.<name>.update" is set to "none" the submodule won't be
> updated no matter how the default is.

OK, so submodule.*.update for each submodule, and a default value
for submodules that do not have submodule.*.update set to anything.

Sounds workable.

> We had two settings in mind,...
> So what if clone would just do an "git submodule init" for now when
> "submodule.autoinit" is set but "submodule.autoupdate" isn't [?]
> ... and a single "submodule.auto" setting would be what users really want?

I do not offhand think of a sensible scenario where you want to init
a submodule once but do not want to update it when the superproject
changes.  Even if the user uses the mode to detach the submodule
HEAD, i.e. the branches in submodules do not matter and the whole
tree is described by the superproject's commit and gitlinks recorded
in it, the user would want the new objects necessary for the updated
superproject, which means a submodule that is init'ed (whether it is
via "git submodule init" or the submodule.autoinit variable) must be
updated.

So I am not sure why a user wants to disable autoupdate in the first
place.  For the same reason, setting submodule.*.update to none
would not make much sense, either.  Perhaps I am missing something.

Unless the user is very conservative and suspects that these
recursive behaviour we are going to bolt on to various commands
could be buggy and untrustworthy, in which case the user might want
to manually run "git submodule update", or even run "git fetch"
after going there while bypassing the whole "git submodule".  But I
do not think that is healthy in the longer run.

Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> > We had two settings in mind,...
> > So what if clone would just do an "git submodule init" for now when
> > "submodule.autoinit" is set but "submodule.autoupdate" isn't [?]
> > ... and a single "submodule.auto" setting would be what users really want?
> 
> I do not offhand think of a sensible scenario where you want to init
> a submodule once but do not want to update it when the superproject
> changes.  Even if the user uses the mode to detach the submodule
> HEAD, i.e. the branches in submodules do not matter and the whole
> tree is described by the superproject's commit and gitlinks recorded
> in it, the user would want the new objects necessary for the updated
> superproject, which means a submodule that is init'ed (whether it is
> via "git submodule init" or the submodule.autoinit variable) must be
> updated.

I agreed that once we have the ability to do so, autoupdating any
initialized submodules should be automatic and non-optional.  However,
making it optional during a transition period while the ability gets
fleshed out would make sense too (so checkout-mode folks can opt in
before we clobber the local-branch folks ;).

Ceers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Heiko Voigt]

On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> > We had two settings in mind,...
> > So what if clone would just do an "git submodule init" for now when
> > "submodule.autoinit" is set but "submodule.autoupdate" isn't [?]
> > ... and a single "submodule.auto" setting would be what users really want?
> 
> I do not offhand think of a sensible scenario where you want to init
> a submodule once but do not want to update it when the superproject
> changes.  Even if the user uses the mode to detach the submodule
> HEAD, i.e. the branches in submodules do not matter and the whole
> tree is described by the superproject's commit and gitlinks recorded
> in it, the user would want the new objects necessary for the updated
> superproject, which means a submodule that is init'ed (whether it is
> via "git submodule init" or the submodule.autoinit variable) must be
> updated.
> 
> So I am not sure why a user wants to disable autoupdate in the first
> place.  For the same reason, setting submodule.*.update to none
> would not make much sense, either.  Perhaps I am missing something.
> 
> Unless the user is very conservative and suspects that these
> recursive behaviour we are going to bolt on to various commands
> could be buggy and untrustworthy, in which case the user might want
> to manually run "git submodule update", or even run "git fetch"
> after going there while bypassing the whole "git submodule".  But I
> do not think that is healthy in the longer run.

I think autoupdate is mainly there for the transition phase. Since
submodule can e.g. contain a lot of files a checkout would take much
longer. Similar to when Jens implemented the recursive diff, many people
were annoyed by the new files showing up and some with the impact on
performance (thats why we have the --ignore-submodules option).

In case of very big submodules and people already ignore their diff it
might even be necessary that the update is only done manually. E.g. for
a big media repository.

Cheers Heiko

Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Heiko Voigt]

On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
> On 05/06/14 07:42, Heiko Voigt wrote:
> > I like this idea of specifying different "views" by giving tags. But
> > does it rule out a boolean clone.recursesubmodules? For the simple case
> > some people might not want to worry about specifying tags but just want
> > to configure: "Yes give me everything". So if we were to do this I would
> > like it if we could have both. Also because the option for clone is
> > --recurse-submodules and our typical schema is that a configuration
> > option is named similar so clone.recursesubmodules would fit here.
> 
> Maybe using a glob pattern would work.
> 
> The user might say
> 
>      [clone]
>          recursesubmodules = x86*
> 
> And .gitmodules might say
> 
>      [submodule "foo"]
>          tags = x86_64
>      [submodule "bar"]
>          tags = x86
>      [submodule "frotz"]
>          tags = powerpc
> 
> For the "Yes give me everything" case the user could say
> 
>      [clone]
>          recursesubmodules = *

Thats interesting. Lets me/us think about that a little more.

> > So either we do this "magically" and all valid boolean values are
> > forbidden as tags or we would need a different config option. Further
> > thinking about it: Maybe a general option that does not only apply to
> > clone would suit the "views" use-case more. E.g. "submodule.tags" or
> > similar.
> > 
> > Also please note: We have been talking about adding two configurations
> > for submodules:
> > 
> > 	submodule."name".autoclone (IIRC)
> > 
> > I am not sure whether that was the correct name, but this option should
> > tell recursive fetch / clone whether to automatically clone a submodule
> > when it appears on a fetch in the history.
> > 
> > 	submodule."name".autoinit
> > 
> > And this one is for recursive checkout and tells whether an appearing
> > submodule should automatically be initialized.
> > 
> > These options fullfill a similar use-case and are planned for the future
> > when recursive fetch/clone and checkout are in place (which is not that
> > far away). We might need to rethink these to incoporate the "views from
> > tags" idea nicely and since we do not want a configuration nightmare.
> 
> I'm a little confused at how autoclone and autoinit differ. Aren't they
> the same? i.e. when this module appears grab it by default. I see
> autoupdate as a little different meaning update it if it's been
> initialised. Also does autoinit imply autoupdate?

autoclone is about cloning the history of submodules. So e.g. when a
submodule first appears in the superprojects history whether it should
automatically be cloned to .git/modules.

autoinit is all about the checkout phase. When a commit with a new
submodule is checked out: Should that new submodule be automatically
initialised?

As far as autoupdate is concerned: Maybe autoinit can imply that it is
enabled, yes. But I guess we still need autoupdate for the case of big
submodules that cause to much performance trouble if updated by every
checkout.

So its actually three values: autoclone, autoinit, autoupdate. Damn,
these configurations become more complicated everytime. Maybe we should
try to clean them, up once we have everything, with Git 3.0 ;-) If
anyone has an idea how to get rid of some right now...

Radically different thinking: How about just one: submodule.auto =
true/false configuration and that means you opt in to doing everything
as automatic as possible. Since we are still implementing we could stick
a prominent warning in the documentation that the user should be
prepared for behavioral changes.

Once everybody is happy with that we could switch the default from false
to true.

> At $dayjob we have a superproject which devs clone this has submodules
> for the important and/or high touch repositories. We have other
> repositories that are normally build from a tarball (or not built at
> all) but we can build them from external repositories if needed. The
> latter case is painfully manual. If autoinit/autoupdate existed we'd
> probably setup out projects with.
> 
>     [submodule "linux"]
>         autoinit = true
> 	autoupdate = true
>     [submodule "userland"]
>         autoinit = true
> 	autoupdate = true
>     [submodule "not-used-that-much"]
> 	autoupdate = true
> 
> We probably wouldn't make use of tags because we're building complete
> embedded systems and generally want everything, even if we are doing
> most of our work on a particular target we need to do builds for other
> targets for sanity checks.

Yep thats exactly what we already do at $dayjob but with
submodule.*.update=none. Since that conveniently also disables the
initialisation, developers only get the basic code and not everyone
needs to have the media and some big external libs.

I would reuse 'update' in the long run. But I guess for the transition
we will need the extra autoupdate one to keep annoyance levels low.

We currently also do not have real use cases for the tags/views
scenario, but as repositories grow I can see that it could be useful so
I would like it if we could keep the configuration open to that.

Cheers Heiko

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Junio C Hamano]

Heiko Voigt <hvoigt@hvoigt.net> writes:

> On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
> ...
>> I'm a little confused at how autoclone and autoinit differ. Aren't they
>> the same? i.e. when this module appears grab it by default. I see
>> autoupdate as a little different meaning update it if it's been
>> initialised. Also does autoinit imply autoupdate?
>
> autoclone is about cloning the history of submodules. So e.g. when a
> submodule first appears in the superprojects history whether it should
> automatically be cloned to .git/modules.
>
> autoinit is all about the checkout phase. When a commit with a new
> submodule is checked out: Should that new submodule be automatically
> initialised?
>
> As far as autoupdate is concerned: Maybe autoinit can imply that it is
> enabled, yes. But I guess we still need autoupdate for the case of big
> submodules that cause to much performance trouble if updated by every
> checkout.

> So its actually three values: autoclone, autoinit, autoupdate. Damn,
> these configurations become more complicated everytime.

I suspect that as an end-user you do not need to set all three in
most cases.  Just like an unspecified autoupdate can default to
whatever autoinit setting for the submodule is, because it is less
likely that a user wants to have a submodule checked out *and* leave
it stale, an unspecified autoinit can default to the autoclone
setting, because it is less likely that a user who does not want to
have a checkout would want to spend network bandwidth to clone it.

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Jens Lehmann]

Am 06.06.2014 07:54, schrieb Heiko Voigt:
> On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
>> On 05/06/14 07:42, Heiko Voigt wrote:
>>> So either we do this "magically" and all valid boolean values are
>>> forbidden as tags or we would need a different config option. Further
>>> thinking about it: Maybe a general option that does not only apply to
>>> clone would suit the "views" use-case more. E.g. "submodule.tags" or
>>> similar.
>>>
>>> Also please note: We have been talking about adding two configurations
>>> for submodules:
>>>
>>> 	submodule."name".autoclone (IIRC)
>>>
>>> I am not sure whether that was the correct name, but this option should
>>> tell recursive fetch / clone whether to automatically clone a submodule
>>> when it appears on a fetch in the history.
>>>
>>> 	submodule."name".autoinit
>>>
>>> And this one is for recursive checkout and tells whether an appearing
>>> submodule should automatically be initialized.
>>>
>>> These options fullfill a similar use-case and are planned for the future
>>> when recursive fetch/clone and checkout are in place (which is not that
>>> far away). We might need to rethink these to incoporate the "views from
>>> tags" idea nicely and since we do not want a configuration nightmare.
>>
>> I'm a little confused at how autoclone and autoinit differ. Aren't they
>> the same? i.e. when this module appears grab it by default. I see
>> autoupdate as a little different meaning update it if it's been
>> initialised. Also does autoinit imply autoupdate?
> 
> autoclone is about cloning the history of submodules. So e.g. when a
> submodule first appears in the superprojects history whether it should
> automatically be cloned to .git/modules.
> 
> autoinit is all about the checkout phase. When a commit with a new
> submodule is checked out: Should that new submodule be automatically
> initialised?

To me those two only make sense together, so I see them as a single
option. But then maybe some developers would like to clone everything
so they are plane-safe in case they intend to do "git submodule
update --init" later at 30.000 feet without internet access ... so
yes, technically we have three distinct steps: clone, init & update.

> As far as autoupdate is concerned: Maybe autoinit can imply that it is
> enabled, yes. But I guess we still need autoupdate for the case of big
> submodules that cause to much performance trouble if updated by every
> checkout.
> 
> So its actually three values: autoclone, autoinit, autoupdate. Damn,
> these configurations become more complicated everytime. Maybe we should
> try to clean them, up once we have everything, with Git 3.0 ;-) If
> anyone has an idea how to get rid of some right now...

I suspect that once they are introduced we'll never be able to get
rid of them again ;-)

> Radically different thinking: How about just one: submodule.auto =
> true/false configuration and that means you opt in to doing everything
> as automatic as possible. Since we are still implementing we could stick
> a prominent warning in the documentation that the user should be
> prepared for behavioral changes.
> 
> Once everybody is happy with that we could switch the default from false
> to true.

I like that. (And if we really need /clone-but-no-init-or-update/ or
/clone-and-init-but-no-update/ settings later we could add two new
values additionally to true/false to make that work with a single
setting too). So I'm convinced that a single option is the way to go.

>> At $dayjob we have a superproject which devs clone this has submodules
>> for the important and/or high touch repositories. We have other
>> repositories that are normally build from a tarball (or not built at
>> all) but we can build them from external repositories if needed. The
>> latter case is painfully manual. If autoinit/autoupdate existed we'd
>> probably setup out projects with.
>>
>>     [submodule "linux"]
>>         autoinit = true
>> 	autoupdate = true
>>     [submodule "userland"]
>>         autoinit = true
>> 	autoupdate = true
>>     [submodule "not-used-that-much"]
>> 	autoupdate = true
>>
>> We probably wouldn't make use of tags because we're building complete
>> embedded systems and generally want everything, even if we are doing
>> most of our work on a particular target we need to do builds for other
>> targets for sanity checks.
> 
> Yep thats exactly what we already do at $dayjob but with
> submodule.*.update=none. Since that conveniently also disables the
> initialisation, developers only get the basic code and not everyone
> needs to have the media and some big external libs.
> 
> I would reuse 'update' in the long run. But I guess for the transition
> we will need the extra autoupdate one to keep annoyance levels low.

I'm not sure reusing 'update' is going to work: 'update' currently
controls what "git submodule update" will do: nothing, checkout,
merge or rebase (and we shouldn't change that because of backwards
compatibility). We're talking about a new setting telling regular
git commands to do the submodule work tree update without having to
manually call "git submodule update". And I believe we'll always
need 'update' as it is for people who'll want to do a manual "git
submodule update", especially when we change the default of
'submodule.auto' to true in 3.0.

And by the way: wouldn't it make more sense to tell the user /what/
we do automatically? So maybe 'submodule.autoupdate' is a better
name for the new switch? The fact that it also does clone and init
under the hood looks more like a technical detail to the user, no?
And I'd like to avoid users uttering "auto-what?" when they hear
about this setting ;-) And it would make clear that 'update' is
what we do and 'autoupdate' makes it happen without having to call
"git submodule update".

Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Mon, Jun 09, 2014 at 03:17:07PM +0200, Jens Lehmann wrote:
> And by the way: wouldn't it make more sense to tell the user /what/
> we do automatically? So maybe 'submodule.autoupdate' is a better
> name for the new switch?

Or autocheckout?  No need to preserve submodule-specific jargon when
we have a perfectly acceptable word for this in the core interface ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Jeremy Morton]

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&&

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Stefan Beller]

On Mon, Oct 3, 2016 at 8:36 AM, Jeremy Morton <admin@game-point.net> wrote:
> Did this ever get anywhere?  Can we recursively update submodules with "git
> pull" in the supermodule now?

I think the idea is sound.

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

Not sure if t7407-submodule-foreach.sh is the best place to put these tests,
as it is not `submodule foreach`, maybe put it into 7400 (though that
is larger already)

>> +test_expect_success 'use "git clone" with clone.recursesubmodules to
>> checkout all submodules' '
>> +       git config --local clone.recursesubmodules true&&

Nit of the day:
I think we prefer a single white space between the line and the ending
&&.

No need for --local as that is the default.
However I'd propose to use test_config here,
as then the option is cleaned up after the test
automatically.

>> +       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

No need to unset it here when test_config is used.

We'd maybe would want to also test that
git -c clone.recursesubmodules clone --no-recursive ...
works as expected (the --no-recursive taking precedence
over the config option)

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Heiko Voigt]

On Mon, Oct 03, 2016 at 10:18:32AM -0700, Stefan Beller wrote:
> On Mon, Oct 3, 2016 at 8:36 AM, Jeremy Morton <admin@game-point.net> wrote:
> > Did this ever get anywhere?  Can we recursively update submodules with "git
> > pull" in the supermodule now?
> 
> I think the idea is sound.

I am confused there is nothing handling *pull* here? This patch was
about clone. Handling 'pull' is a much bigger topic[1].

Cheers Heiko

[1] https://github.com/jlehmann/git-submod-enhancements/wiki/Recursive-submodule-checkout

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Jeremy Morton]

Did this ever get anywhere?  If not why not?  It would be very useful 
to me to be able to clone recursively by default, especially 
considering you can't use 'alias' to override the existing 'clone' 
command.

-- 
Best regards,
Jeremy Morton (Jez)

On 06/06/2014 06:26, Heiko Voigt wrote:
> On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote:
>> Jens Lehmann<Jens.Lehmann@web.de>  writes:
>>> We had two settings in mind,...
>>> So what if clone would just do an "git submodule init" for now when
>>> "submodule.autoinit" is set but "submodule.autoupdate" isn't [?]
>>> ... and a single "submodule.auto" setting would be what users really want?
>>
>> I do not offhand think of a sensible scenario where you want to init
>> a submodule once but do not want to update it when the superproject
>> changes.  Even if the user uses the mode to detach the submodule
>> HEAD, i.e. the branches in submodules do not matter and the whole
>> tree is described by the superproject's commit and gitlinks recorded
>> in it, the user would want the new objects necessary for the updated
>> superproject, which means a submodule that is init'ed (whether it is
>> via "git submodule init" or the submodule.autoinit variable) must be
>> updated.
>>
>> So I am not sure why a user wants to disable autoupdate in the first
>> place.  For the same reason, setting submodule.*.update to none
>> would not make much sense, either.  Perhaps I am missing something.
>>
>> Unless the user is very conservative and suspects that these
>> recursive behaviour we are going to bolt on to various commands
>> could be buggy and untrustworthy, in which case the user might want
>> to manually run "git submodule update", or even run "git fetch"
>> after going there while bypassing the whole "git submodule".  But I
>> do not think that is healthy in the longer run.
>
> I think autoupdate is mainly there for the transition phase. Since
> submodule can e.g. contain a lot of files a checkout would take much
> longer. Similar to when Jens implemented the recursive diff, many people
> were annoyed by the new files showing up and some with the impact on
> performance (thats why we have the --ignore-submodules option).
>
> In case of very big submodules and people already ignore their diff it
> might even be necessary that the update is only done manually. E.g. for
> a big media repository.
>
> Cheers Heiko
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

[Stefan Beller]

On Wed, Aug 2, 2017 at 11:11 AM, Jeremy Morton <admin@game-point.net> wrote:
> Did this ever get anywhere?  If not why not?  It would be very useful to me
> to be able to clone recursively by default, especially considering you can't
> use 'alias' to override the existing 'clone' command.
>

Note that there is 3c548de378 (Merge branch 'sb/submodule-blanket-recursive',
2017-06-13), which adds recursing into submodules to a couple of commands.

clone is not one of them, because at that time I thought you'd want to select
explicitly at clone time which submodules you want. Unlike most other commands
that can recurse into submodules, clone supports a pathspec for the recurse
parameter, such that you can express a fine grained selection of submodules
that you are interested in.

I wonder if submodule.recurse is set if we'd just want to recurse into
all submodules for clone? That may have negative consequences though
as people may have forgotten that they set that config a long time ago and then
are surprised to get so many submodules.