Jens Lehmann <> writes:

> Am 25.11.2013 22:01, schrieb Junio C Hamano:
>> Jens Lehmann <> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to