Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > Am 25.11.2013 22:01, schrieb Junio C Hamano: >> Jens Lehmann <Jens.Lehmann@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html