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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 05.12.2013 00:19, schrieb Heiko Voigt:
> On Wed, Dec 04, 2013 at 02:32:46PM -0800, Junio C Hamano wrote:
> This series tries to achieve the following goals for the
> submodule.<name>.ignore=all configuration or the --ignore-submodules=all
> command line switch.

Thanks for the summary.

>  * Make git status never ignore submodule changes that got somehow in the
>    index. Currently when ignore=all is specified they are and thus
>    secretly committed. Basically always show exactly what will be
>    committed.

Yes, what's in the index should always be shown as such even when the
user chose to ignore the work tree differences of the submodule.

>  * Make add ignore submodules that have the ignore=all configuration when
>    not explicitly naming a certain submodule (i.e. using git add .).
>    That way ignore=all submodules are not added to the index by default.
>    That can be overridden by using the -f switch so it behaves the same
>    as with untracked files specified in one of the ignore files except
>    that submodules are actually tracked.

I think we should do this part in a different series, as everybody
seems to agree that this should be fixed that way and it has nothing
to do with what is ignored in submodule history.

>  * Let diff always show submodule changes between revisions or
>    between a revision and the index. Only worktree changes should be
>    ignored with ignore=all.
> 
>  * Generally speaking: Make everything that displays diffs in history,
>    diffs between revisions or between a revision and the index always
>    show submodules changes (only the commit ids) even if a submodule is
>    specified as ignore=all.

I'm not so sure about that. Some scripts really want to ignore the
history of submodules when comparing a rev to the index:

git-filter-branch.sh:			git diff-index -r --name-only --ignore-submodules $commit &&
git-pull.sh:    git diff-index --cached --name-status -r --ignore-submodules HEAD --
git-rebase--merge.sh:	if ! git diff-index --quiet --ignore-submodules HEAD --
git-sh-setup.sh:	if ! git diff-index --cached --quiet --ignore-submodules HEAD --
git-stash.sh:	git diff-index --quiet --cached HEAD --ignore-submodules -- &&

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. But it looks like we need to
keep "all".

>  * If ignore=all for a submodule and a diff would usually involve the
>    worktree we will show the diff of the commit ids between the current
>    index and the requested revision.

I agree if we make that "ignore=worktree".

>> I do think that it is a good thing to make what "git add ." does and
>> what "git status ." reports consistent, and "git add ." that does
>> not add everything may be a good step in that direction

Yup, as written above I'd propose to start with that too.

>> (another
>> possible solution may be to admit that ignore=all was a mistake and
>> remove that special case altogether, so that "git status" will
>> always report a submodule that does not match what is in the HEAD
>> and/or index).

No, looking at the git-scripts that use it together with diff-index it
wasn't a mistake. But we might be missing a less drastic option ;-)

> I think it was too early to add ignore=all back then when the ignoring
> was implemented. We did not think through all implications. Since people
> have always been requesting the floating model and as it seems started
> using it I am not so sure whether there is not a valid use case. Maybe
> Sergey can shed some light on their actual use case and why they do not
> care about the precise revision most of the time.

You maybe right about not thinking things thoroughly through, but we
helped people that rightfully complained when the (then new) submodule
awareness broke their scripts.

> For example the case that all developers always want to work with some
> HEAD revision of all submodules and the build system then integrates
> their changes on a regular basis. When all went well it creates commits
> with the precise revisions. This way they have some stable points as
> fallback or for releases. Thats at least the use case I can think of but
> maybe there are others.

And that could be the "worktree" value.

Below is a hack that disables the diffing of rev and index, but not
that against the work tree. It breaks t4027-diff-submodule.sh,
t7003-filter-branch.sh and t7508-status.sh as expected:

---------------------->8--------------------
diff --git a/diff.c b/diff.c
index e34bf97..ed66a01 100644
--- a/diff.c
+++ b/diff.c
@@ -4813,7 +4813,7 @@ static int is_submodule_ignored(const char *path, struct d
        if (DIFF_OPT_TST(options, IGNORE_SUBMODULES))
                ignored = 1;
        options->flags = orig_flags;
-       return ignored;
+       return 0;
 }

 void diff_addremove(struct diff_options *options,