From: Jens Lehmann Date: Thu, 24 Feb 2011 23:44:41 GMT Subject: Re: [1.8.0] Don't copy "submodule..update" to .git/config on submodule init Message-ID: <4D66ED69.7090806@web.de> In-Reply-To: <7vwrkq46e2.fsf@alter.siamese.dyndns.org> Am 24.02.2011 01:34, schrieb Junio C Hamano: > Jens Lehmann 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).