On Mon, Nov 21, 2016 at 11:07 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> So I guess we should test a bit more extensively, maybe >> >> git status >expect >> git submodule embedgitdirs >> git status >actual >> test_cmp expect actual >> # further testing via >> test -f .. >> test -d .. > > Something along that line. "status should succeed" does not tell > the readers what kind of breakage the test is expecting to protect > us from. If we are expecting a breakage in embed-git-dirs would > somehow corrupt an existing submodule, which would lead to "status" > that is run in the superproject report the submodule differently, > then comparing output before and after the operation may be a > reasonable test. Going there to the submodule working tree and > checking the health of the repository (of the submodule) may be > another sensible test. and by checking the health you mean just a status in there, or rather a more nuanced thing like `git rev-parse HEAD` ? I'll go with that for now. > >>> In the >>> extreme, if the failed "git submodule" command did >>> >>> rm -fr .git ?* && git init >>> >>> wouldn't "git status" still succeed? >> >> In that particular case you'd get >> $ git status >> fatal: Not a git repository (or any parent up to mount point ....) > > Even with "&& git init"? Or you forgot that part? yes I did, because why would you run init after an accidental rm -rf ... ?