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

[Heiko Voigt <hvoigt@hvoigt.net>]

On Wed, Dec 04, 2013 at 02:32:46PM -0800, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
> 
> > This is my current work in progress. Sergey it would be awesome if you
> > could test these and tell me whether the behaviour is what you would
> > expect. Once that is settled I will add some tests and possibly clean up
> > some code.
> >
> > Since nobody spoke against this change of behavior I assume that we
> > agree on the general approach I am taking here. If not please speak up
> > now so we can work something out and save me implementation time ;-)
> >
> > Whats still missing is:
> 
> Before listing what's missing, can you describe what "the general
> approach" is?  After all, that is what you are assuming that has got
> a silent concensus, but without getting it spelled out, others would
> easily miss what they "agreed" to.

Definitely, sorry I missed that (isn't it obvious ;-)):

This series tries to achieve the following goals for the
submodule.<name>.ignore=all configuration or the --ignore-submodules=all
command line switch.

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

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

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

 * 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 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 (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).

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.

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.

Cheers Heiko