Re: [PATCH 3/3] submodule--helper: add intern-git-dir function
- From
Stefan Beller <sbeller@google.com>
- Date
- Nov 22, 2016, 17:16 UTC
- Message-ID
- <CAGZ79kb7062abd6Cbf-ey3u0L6PXUcRf7m-og5EyCRZencOR6g@mail.gmail.com>
- In-Reply-To
- <xmqqmvgsf0wo.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 21, 2016 at 11:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
> Stefan Beller <sbeller@google.com> 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.
Show 13 quoted lines
> >>> 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 ... ?