Subject: Re: [1.8.0] Don't copy "submodule.<name>.update" to .git/config on submodule init

From: Jens Lehmann <[email-masked]>
Date: Fri, 25 Feb 2011 00:44:41 +0100

Am 24.02.2011 01:34, schrieb Junio C Hamano:
> Jens Lehmann <[email-masked]> writes:
> In any case, URL is a good example of variables that would want to stay
> around (while giving the user helping hand to update it when choice
> changes).  "update" would be a good example of a variable that may want to
> be per branch (e.g. 'maint' might encourage "checkout" while 'master'
> might encourage "rebase").  So most likely we would need to support both
> modes of operation.

Yeah, I totally agree that the URL has to be copied to .git/config and
must be updated only on the users request. I'm not sure the "giving the
user a helping hand" approach will work so well as I suspect switching
back and forth between branches might spam the user with helping hands
every time, but maybe I'm missing something here.

>> Should we ask the user if he wants to fetch the bare submodule into the
>> .git directory of the superproject or to ignore the clone setting while
>> fetching?
> 
> If we don't know what the user wants yet, yes.  Note that explicit command
> line options "git clone --recursive" and $HOME/.gitconfig counts as the
> user letting us know what s/he wants.

Looks like we are in the same boat here. Only if either the always-recurse
or on-demand mode for fetch is enabled - either by command line or by
configuration - fetch should do that automatically. Otherwise it would do
nothing (me not being so sure about the feasibility of asking the user).