From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 01 Sep 2016 19:19:44 GMT
Subject: Re: git submodules implementation question
Message-ID: <xmqqa8frwhpr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kZnhNVBy6Oqt=x8m0jZj_tGNkMPPBBr+aL6DToOYtv9vQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> 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.