On Wed, Feb 15, 2017 at 9:04 AM, Brandon Williams [off-list ref] wrote:

On 02/14, Stefan Beller wrote:

quoted

In later patches we introduce the --recurse-submodule flag for commands
that modify the working directory, e.g. git-checkout.

It is potentially expensive to check if a submodule needs an update,
because a common theme to interact with submodules is to spawn a child
process for each interaction.

So let's introduce a function that pre checks if a submodule needs
to be checked for an update.

Signed-off-by: Stefan Beller <redacted>
---
 submodule.c | 26 ++++++++++++++++++++++++++
 submodule.h |  8 ++++++++
 2 files changed, 34 insertions(+)

diff --git a/submodule.c b/submodule.c
index c0060c29f2..4c33374ae8 100644
--- a/submodule.c
+++ b/submodule.c

@@ -551,6 +551,32 @@ void set_config_update_recurse_submodules(int value)
      config_update_recurse_submodules = value;
 }

+int submodules_interesting_for_update(void)
+{
+     /*
+      * Update can't be "none", "merge" or "rebase",
+      * treat any value as OFF, except an explicit ON.
+      */
+     return config_update_recurse_submodules == RECURSE_SUBMODULES_ON;
+}
+
+int is_interesting_submodule(const struct cache_entry *ce)

Is there perhaps a more descriptive function name we could use instead
of "is_interesting"?  The problem is that its difficult to know why its
interesting or for what purpose it is interesting.

I should finish the background story patch first. By 'is_interesting' I mean
* it is active/initialized/"The user expressed interested in the submodule by
  setting submodule.<name>.URL
* its submodule.<name>.update strategy is != NONE.

The second point is interesting, as that entertains the thought that we'll pay
attention to the submodule.<name>.update strategy at all and
we may want to also implement rebase/merge eventually.

So I think we'd want to tighten that down to "checkout" only for now.

Thanks,
Stefan