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

Jens Lehmann [off-list ref] 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.

Am 24.02.2011 01:34, schrieb Junio C Hamano:

Jens Lehmann [off-list ref] 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.

quoted

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).