Am 09.06.2010 00:11, schrieb Johan Herland: > On Tuesday 08 June 2010, Jens Lehmann wrote: >> After thinking some time about peoples expectations and troubles >> with the recursive scanning of submodules, I came up with this: >> >> What about expanding the "--ignore-submodules" option of the git diff >> family with three parameters: >> >> --ignore-submodules=all : Same behavior as "--ignore-submodules", >> submodules show never up as modified. >> >> --ignore-submodules=untracked : Don't consider submodules as modified >> when they only contain untracked files, but do if the commits in the >> superproject are different or tracked content is modified. >> >> --ignore-submodules=dirty : Don't consider submodules as modified >> when their work tree is dirty, no matter why. This is the pre 1.7.0 >> behavior and doesn't recurse into submodules at all. > > Pardon my ignorance: Does this make "dirty" a superset of "untracked"? Or > are they orthogonal. And how does "all" compare to "dirty"? Are they > synonyms, or is "all" a superset of "dirty"? Sorry I didn't make that clear enough: "all" is a superset of "dirty" and "dirty" is a superset of "untracked". There are currently (since 1.7.0) three reasons a submodule is considered dirty: 1) It contains untracked content 2) It contains modified tracked content 3) It contains newer commits than those committed in the superproject "all" would ignore 1), 2) & 3) "dirty" would ignore 1) & 2) "untracked" would ignore 1) > I agree with adding support for this in .gitmodules, to allow customizing on > a per-submodule level. Yup, and different branches could handle that differently that way too. -- 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