Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

[Jeff King <peff@peff.net>]

On Thu, Jan 19, 2017 at 11:30:23AM -0800, Stefan Beller wrote:

> Now let's ask the same question for "git -C sub status ." (which is a
> command that is only reading and not writing to the repository)
> 
> 1) If the submodule is populated, the user clearly intended to know
>    more about the submodules status
> 2) It is unclear if the user wanted to learn about the submodules state
>    (So ideally: "The submodule 'sub' is not initialized. To init ...")
>    or the status check should be applied to the superproject instead.
> 
> Avoid the confusion in 2) as well and just error out for now. Later on
> we may want to add another flag to git.c to allow commands to be run
> inside unpopulated submodules and each command reacts appropriately.

I like the general idea of catching commands in unpopulated submodules,
but I'm somewhat uncomfortable with putting an unconditional check into
git.c, for two reasons:

  1. Reading the index can be expensive. You would not want "git
     rev-parse" to incur this cost.

  2. How does this interact with commands which do interact with the
     index? Don't they expect to find the_index unpopulated?

     (I notice that it's effectively tied to RUN_SETUP, which is good.
      But that also means that many commands, like "diff", won't get the
      benefit. Not to mention non-builtins).

I'd rather see it in the commands themselves. Especially given the
"ideal" in your status example, which requires command-specific
knowledge.

-Peff