Stefan Beller <sbeller@xxxxxxxxxx> writes: >> The final version needs to be accompanied with tests to show the >> effect of this change for callers. A test would set up a top-level >> and submodule, deliberately break submodule/.git/ repository and >> show what breaks and how without this change. > > Tests are really good at providing this context as well, or to communicate > the actual underlying problem, which is not quite clear to me. > That is why I refrained from jumping into the discussion as I think the > first few emails were dropped from the mailing list and I am missing context. I do not know where you started reading, but the gist of it is that submodule.c spawns subprocess to run in the submodule's context by assuming that chdir'ing into the <path> of the submodule and running it (i.e. cp.dir set to <path> to drive start_command(&cp)) is sufficient. When <path>/.git (either it is a directory itself or it points at a directory in .git/module/<name> in the superproject) is a corrupt repository, running "git -C <path> command" would try to auto-detect the repository, because it thinks <path>/.git is not a repository and it thinks it is not at the top-level of the working tree, and instead finds the repository of the top-level, which is almost never what we want.