Re: Git issues with submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 26, 2013, 19:33 UTC
Message-ID: <xmqq1u23vty1.fsf@gitster.dls.corp.google.com>
In-Reply-To: <5294EC11.2010405@web.de>

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

Show 19 quoted lines

> 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.