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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 5, 2014, 18:18 UTC
Message-ID: <xmqq4mzzte2z.fsf@gitster.dls.corp.google.com>
In-Reply-To: <538F6E52.9000009@web.de>

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

Show 6 quoted lines

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