Re: [PATCH 0/2] Add optional parameters to the diff option "--ignore-submodules"

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 8, 2010, 22:19 UTC
Message-ID: <4C0EC201.9060309@web.de>
In-Reply-To: <201006090011.14995.johan@herland.net>

Am 09.06.2010 00:11, schrieb Johan Herland:

Show 21 quoted lines

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