Re: Git issues with submodules

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> Am 25.11.2013 22:01, schrieb Junio C Hamano:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> 
>>> Looking good to me. Please add tests for "diff.ignoreSubmodules"
>>> and "submodule.<name>.ignore", the latter both in .gitmodules and
>>> .git/config. While doing some testing for this thread I found an
>>> inconsistency in git show which currently honors the submodule
>>> specific option only from .git/config and ignores it in the
>>> .gitmodules file ...
>> 
>> Sorry, but isn't that what should happen?  .git/config is the
>> ultimate source of the truth, and .gitmodules is a hint to prime
>> that when the user does "git submodule init", no?
>
> "git submodule init" only copies the "update" and "url" settings
> to .git/config, all others default to the value they have in the
> .gitmodules file if they aren't found in .git/config. This allows
> upstream to change these settings unless the user copies them to
> .git/config himself.

I know what the code does. I was questioning if "only copies X and
Y" is a sensible thing.

Copying at init time will fix the values when copied and give the
user a stable and dependable behaviour.  I have a feeling that the
current "not copy to fix it to a stable value, but look into
.gitmodules as a fallback" was not a designed behaviour for the
other properties, but was done by accident and/or laziness.