Re: [PATCH] submodule: add 'deinit' command

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

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

> Maybe the principle of least surprise is better followed when we
> nuke the whole section, as it might surprise the user more to have
> a setting resurrected he customized in the last life cycle of the
> submodule than seeing that after an deinit followed by an init all
> former customizations are consistently gone. So I tend to think now
> that removing the whole section would be the better solution here.

I tend to agree; I suspect that a "deinit" would be mostly done
either to

 (1) correct mistakes the user made during a recent "init" and
     perhaps "sync"; or

 (2) tell Git that the user has finished woing with this particular
     submodule and does not intend to use it for quite a while.

For both (1) and (2), I think it would be easier to users if we gave
them a clean slate, the same state as the one the user who never had
ran "init" on it would be in.  A user in situation (1) is asking for
a clean slate, and a user in situation (2) is better served if he
does not have to worry about leftover entries in $GIT_DIR/config he
has long forgotten from many months ago (during which time the way
the project uses the particular submodule may well have changed)
giving non-standard experience different from what other project
participants would get.

If there were a sane workflow where it makes sense to frequently run
"deinit" followed by some operation followed by "init", it may be
helpful to have an option to keep the other customization.  And one
consideration when implementing that "deinit --keep-customization"
option might be to introduce the submodule.$name.activated boolean;
that way, the operation can keep the customized upstream URL.

In any case, it needs to be shown that such a workflow exists in the
first place to justify "deinit --keep-customization".  I think the
default should be to remove the submodule.$name section.