Re: [RFC/WIP PATCH 0/4] less ignorance of submodules for ignore=all

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> I didn't check each site in detail, but I suspect each ignore option
> was added on purpose to fix a problem. That means we still need "all"
> (at least when diffing rev<->index). Unfortunately that area is not
> covered well in our tests, I only got breakage from the filter-branch
> tests when teaching "all" to only ignore work tree changes (see at the
> end on how I did that).
>
> So I'm currently in favor of adding a new "worktree"-value which will
> only ignore the work tree changes of submodules, which seems just what
> the floating submodule use case needs.

Could you help me clarify what it exactly mean to only ignore the
work tree changes?  Specifically, if I have a submodule directory
whose (1) HEAD points at a commit that is the same as the commit
that is recorded by the top-level's gitlink, (2) the index may or
may not match HEAD, and (3) the working tree contents may or may not
match the index or the HEAD, does it only have the work tree
changes?

If the HEAD in the submodule directory is different from the commit
recorded by the top-level's gitlink, but the index and the working
tree match that different HEAD, I am guessing that it no longer is
with "only the work tree changes" and shown as modified.

If that is the suggestion, it goes back to the very original Git
submodule behavour where we compare $submoduledir/.git/HEAD with the
commit object name expected by the top-level and say the submodule
does not have any change when and only when these two object names
are the same, which sounds like a very sensible default behaviour
(besides, it is very cheap to check ;-).