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

[Johan Herland <johan@herland.net>]

On Wednesday 09 June 2010, Jens Lehmann wrote:
> 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

I guess 3) really means that the submodule's HEAD points to a _different_ 
(not necessarily _newer_) commit than what's referenced in the superproject.

> "all" would ignore 1), 2) & 3)
> "dirty" would ignore 1) & 2)
> "untracked" would ignore 1)

...and just to complete my understanding of this, 3) requires only checking 
the submodule's current HEAD, while 1) and 2) require traversing its work 
tree (i.e. the equivalent of a 'git status'), hence the potential 
expensiveness.

Also, I guess 2) includes both staged and unstaged modifications to tracked 
content?

Thanks for your help. All the ideas in your cover letter seem good to me.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net