Re: Submodule regression in 2.14?

Stefan Beller [off-list ref] writes:

quoted

In the past "submodule.<name>.update=none" was an easy way
to selectively disable certain Submodules.

How would I do this with Git 2.14?

    submodule.<name>.active = false

quoted

My gut feeling is that all commands should respect the
"submodule.<name>.update=none" setting.

Well my gut feeling was that the "update" part of the name
reponds to the subcommand, not the generic action.

For example when you set update=none, git-status,
recursive git-diff still reported the submodule.

Both status and diff are read-only operations, so this smells like a
bit bogus argument made by comparing apples and oranges.

I think Lars is more interested in operations that actually affects
the state of submodules by updating them---"submodule update" may be
a prime example as it goes down to run fetch, pull and/or checkout.
It may have been the only thing that affected the state of
submodules before the "--recurse-submodules" option was added to
commands that affect the state of the (super)project, but I would
think that it is not so wrong to expect that these state-affecting
operations running in the "recurse into submodules" mode to honor
"do not update this submodule" that used to be honored only by
"submodule update".