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

From: Jeff King <peff@peff.net>
Date: Jan 20, 2017, 19:17 UTC
Message-ID: <20170120191728.l3ne5tt5pwbmafjh@sigill.intra.peff.net>
In-Reply-To: <20170119193023.26837-1-sbeller@google.com>

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

Show 12 quoted lines

> 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