Am 24.02.2011 01:34, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html