Jens Lehmann <Jens.Lehmann@xxxxxx> 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.
--
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