Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > And now I read that again I notice that I forgot to add a very important > sentence, sorry about that: > > "Take the setting from .gitmodules if submodule.<name>.update is not > configured by the user in .git/config." Yeah, that changes everything. > My proposal uses the values in .gitmodules for those proposed by upstream > and those in .git/config as those tweaked by the user. Isn't that simpler > than 1) and 2) while giving us the same functionality? It actually is even more flexible, in that it allows the user to say "I don't care either way; I'll follow along whatever the version that I happen to have checked out says"; I am however tempted to think that this particular flexibility is not necessarily a good thing to have. > And additionally it > is not setting the upstream default in stone (which is rather arbitrary as > it just happened to be present in our .gitmodules when we did the "git > submodule init" and might be different at another point in the history)? If the setting changes the behaviour of the command so drastically, would the "I'll follow along" mode be really sensible? A setting in .gitmodules might be different between 'maint' and 'master' from the upstream and depending on which branch is checked out and you are working on, you may get different behaviour (e.g. 'checkout' vs 'merge' vs 'rebase' depending on the value-of-the-day in submodule.<name>.update). Depending on the nature of the setting, it may or may not be. The "record once and then help the users to adjust but make aware of the new duggestion" actually comes from a very old discussion circa 1.5.2 days: Cf. http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621 Imagine the upstream URL to fetch submodule from has changed over time. You don't want to interact with an ancient and now defunct URL only because you happen to have a checkout of an old version by reading from its .gitmodules file. The (2) and (3) in the previous message when taken to their logical conclusion will be the "seen values" that is hinted in the above message from May 2007. Let the user record what s/he wants under the condition that s/he has seen these choices, and do not bother her/im again when choices do not change, but do ask permission and/or confirmation when a new choice appears. git-submodule script hasn't learned to do that yet, unfortunately. 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. > Consider the following situation: The .git directories of the submodules > reside in the .git directory of the superproject so their work trees can > be safely deleted and we have means to let upstream configure which > submodules should be populated on clone. (Hopefully this is the future ;-) Yes, this is very much needed and that is one of the reasons we introduced the support for textual ".git" file. > What happens when we fetch a commit which records a new submodule marked > to be populated on clone in the .gitmodules of that commit? I assume we Marked by who? The supplier of the superproject? > would want to fetch the bare submodule into a subdirectory of the .git > directory of the superproject so that we have it present so we can > populate it when the superproject's commit is checked out later, no? If the user consents (e.g. "git clone --recursive"), yes. > 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. > ... Should we ask him again on checkout time if he wants to use the > upstream setting of checking out the submodule? Yes if the available choice and/or suggestion by the upstream has changed, otherwise no. -- 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