Re: [1.8.0] Don't copy "submodule.<name>.update" to .git/config on submodule init
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Feb 24, 2011, 23:44 UTC
- 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:
Show 7 quoted lines
> Jens Lehmann <Jens.Lehmann@web.de> 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.
Show 7 quoted lines
>> 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).