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. When for example
upstream wants to provide a branch for hacking on an otherwise
ignored submodule, it cannot do that without the users intervention
right now.
This change also makes sense in preparation of recursive submodule
checkout, as that will be controlled by this option. Also notice
that the proposed behavior is already used for the "ignore" and
"fetchRecurseSubmodules" entries.
History:
I can't tell why that copy is done as I wasn't following the list
closely at the time this was implemented. Maybe someone else can
shed some light on that?
Risks:
Users could be surprised that upstream can change the value of the
"update" configuration when the submodule was initialized with a
git version >= 1.8.0.
Migration plan:
In 1.8.0 stop copying the "submodule.<name>.update" entries into
.git/config and add an option ("--update"?) to reactivate the old
behavior of "git submodule init" if the user wants that. Announce
both in the release notes of 1.8.0.
--
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