Jens Lehmann [off-list ref] writes:
quoted
So, .gitmodules initially controls recursion. When a submodule gets
populated, it gets an entry in .git/config which then determines the
recursion behavior from then on. Changing branches might change .gitmodules,
but anything in .git/config will persist so any customizations the user makes
will also persist.
Yes. Upstream can give sane defaults but the user has the last word.
If .git/config entries are created _automatically_ based on the initial
.gitmodules, doesn't that means it will cease to respect the upstream
defaults in the case where .gitmodules changes, even if the user didn't
actually change anything himself...?
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
On 02/21/2011 07:51 PM, Miles Bader wrote:
Jens Lehmann [off-list ref] writes:
quoted
quoted
quoted
quoted
So, .gitmodules initially controls recursion. When a submodule gets
populated, it gets an entry in .git/config which then determines the
recursion behavior from then on. Changing branches might change .gitmodules,
but anything in .git/config will persist so any customizations the user makes
will also persist.
Yes. Upstream can give sane defaults but the user has the last word.
If .git/config entries are created _automatically_ based on the initial
.gitmodules, doesn't that means it will cease to respect the upstream
defaults in the case where .gitmodules changes, even if the user didn't
actually change anything himself...?
Also consider that the .gitmodules' "upstream defaults" may have many
changes
within the existing repository. So, $(git checkout foo) will load some
"defaults" and
$(git checkout bar) may load different "defaults". I guess the defaults
can be migrated
into .git/config using $(git submodule init)...?
Phil
Am 22.02.2011 03:32, schrieb Phil Hord:
On 02/21/2011 07:51 PM, Miles Bader wrote:
quoted
Jens Lehmann [off-list ref] writes:
quoted
quoted
quoted
quoted
So, .gitmodules initially controls recursion. When a submodule gets
populated, it gets an entry in .git/config which then determines the
recursion behavior from then on. Changing branches might change .gitmodules,
but anything in .git/config will persist so any customizations the user makes
will also persist.
Yes. Upstream can give sane defaults but the user has the last word.
If .git/config entries are created _automatically_ based on the initial
.gitmodules, doesn't that means it will cease to respect the upstream
defaults in the case where .gitmodules changes, even if the user didn't
actually change anything himself...?
Yes, unfortunately that is the current behavior of the git-submodule
command, it copies the "update" entry into .git/config on init (but
not on sync, so it is not updated then if it changed). The other
submodule flags ("ignore" & "fetchRecurseSubmodules" don't show that
behavior, the user has to copy them herself to override upstream
settings). I'm in favor of removing that copy and using the setting
from .gitmodules when "update" is not found in .git/config, but this
changes behavior. But maybe that is a worthwhile change for 1.8.0
preparing for the things to come?
Also consider that the .gitmodules' "upstream defaults" may have many
changes
within the existing repository. So, $(git checkout foo) will load some
"defaults" and
$(git checkout bar) may load different "defaults".
Yes, and that is a feature. E.g. when you have a "working on foo"
branch you can set the "fetchRecurseSubmodules" to "yes" there because
you want to get all commits in the submodule to be able to commit some
new ones in the superproject. But in every other branch setting that to
"on-demand" will suffice.
I guess the defaults
can be migrated
into .git/config using $(git submodule init)...?
Not with "git submodule init", as they then would be set in stone from
the beginning. But I can imagine a "git submodule config <setting>"
helper program, which copies the setting into .git/config or updates
it there when wanted.