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

Jens Lehmann [off-list ref] writes:

Proposal:

Stop copying the "submodule.<name>.update" entries into .git/config
on "git submodule init". The current behavior makes it impossible
for upstream to change defaults later, as this value can only be
altered through user intervention when it resides in .git/config.
This is a good thing when he chose to copy it there, but it doesn't
seem to make much sense doing it by default.

Doesn't it just come from the usual "upstream can give a sane default as
recommendation to users who may not bother to set up .git/config, and the
user can tweak that if that doesn't suit his/her needs" convention?

I have a feeling that the correct fix (not limited to "update" but all the
submodule related configuration that share the same "give default, allow
tweak" philosophy) is to:

 (1) record submodule.<name>.update at initialization time, to allow the
     upstream a chance to give a sensible default, as we do now;

 (2) in addition to that, record the fact that the value came as upstream
     default.  You could do so in multiple ways:

     a) record the commit that gave the suggested default to .git/config,
     perhaps submodule.<name>.defaultedFrom (notice that this is
     independent from "update", and covers all such configuration
     variables with a single value); or

     b) record the value the upstream gave to .git/config in a separate
     variable, perhaps submodule.<name>.updateSuggested; or

     c) some other clever way you can think of, as long as it lets us do
     the next step.

 (3) when updating from the upstream results in a change in .gitmodules
     file that changes the previously suggested default the user
     considered, tell that to the user and have him/her choose.  If you
     took (a) in the previous step, you can use "git diff" to determine if
     the suggested default has changed; if you took (b) in the previous
     step, you can compare submodule.<name>.update in .gitmodules with
     submodule.<name>.updateSuggested to do so; if you did (c), you are on
     your own ;-).  After the user updates (or chooses to keep the current
     setting), record the current suggested default just like you did at
     the init time in step (2).

One thing to be careful is in (3) you should not bother users who chose to
ignore the upstream default (i.e. has submodule.<name>.update set
differently from what is suggested by the .gitmodules at the time of
initialization).  The reason (3) updates the "current suggested default"
is exactly for that purpose---the user has seen what the last suggested
default was, and decided to either go with it or have his/her own setting.