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

[Junio C Hamano <gitster@pobox.com>]

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.