Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > The first patch in this series lets "git submodule summary" and "git > submodule status" ignore dirty submodules. I thought about teaching > them a "--ignore" option too, but didn't for two reasons: First, the > output of those commands is pretty much focused on commits. Second, > when using "git status" with the config option 'status.submodulesummary' > the submodule tree is scanned twice, once for "git status" and then > again for "git submodule summary". With this patch the second run is > gone, which is a big gain for users of 'status.submodulesummary' with > large submodules. > > The second patch teaches "git status" the same "--ignore-submodules" > option that "git diff" recently learned. Ignoring all changes also > suppresses the output of "git submodule summary" when > 'status.submodulesummary' is set. > > After this series I am planning to add a config option 'ignore' to > .gitmodules, which can be set for each submodule to either "all", > "dirty", "untracked" or "none" (the default). "git diff" and "git > status" will use that config value for each submodule. Using > "--ignore-submodule" overrides this default (and the new parameter > "none" will be added there to able to override the config settings). > And to avoid having to do "git submdule sync" every time that option > changes, I would like to search for it in .git/config first. If it > is not found there, it will be taken from .gitmodules, if present. > So users can override the setting but if they don't, upstream can > change it easily (e.g. when a submodules .gitignore has been updated > so that "ignore=untracked" is no longer necessary anymore it can be > removed). Also switching branches will have an effect instantly if > the 'ignore' entry in .gitmodules is different between branches. > > Opinions? I think both patches make sense. It would be reassuring to hear from people who are heavier submodule users than me, though... Thanks. -- 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