Re: Submodule regression in 2.14?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 18, 2017, 19:10 UTC
Message-ID: <xmqqpobsbsk1.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaC-rtfp-AMdpkpCycgk568eU2y-JDGwdoSK_E=oUJo-w@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 15 quoted lines

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