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