On Sat, Jan 21, 2017 at 2:17 AM, Jeff King <peff@xxxxxxxx> wrote: > 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. I agree. It's already bad enough for pathspec code to peek into the index, adding a hidden dependency between parse_pathspec() and read_cache(). And I still think parse_pathspec() is not the right place to check submodule paths. Worktree should be checked as well, in the case that the submodule is not yet registered in the index. The right place to do that is per-command, with their consent so to speak, because they may need to set things up (index, .git/config and stuff) properly before explicitly doing this check. -- Duy