Re: [RFC-PATCHv2] submodules: add a background story

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 14, 2017, 22:17 UTC
Message-ID: <xmqqmvdo76yw.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbjSLaUsJH_KuT6EiC+Kt-87+GjONt08hCytXULecMijA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 21 quoted lines

> On Tue, Feb 14, 2017 at 1:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>> If we were to redesign the .gitmodules file, we might have it as
>>>
>>>     [submodule "path"]
>>>         url = git://example.org
>>>         branch = .
>>>         ...
>>>
>>> and the "path -> name/UID" mapping would be inside $GIT_DIR.
>>
>> I am not sure how you are going to keep track of that mapping,
>> though.  If .gitmodules file does not have a way to tell that what
>> used to be at "path" in its v1.0 is now at "htap" (instead the above
>> seems to assume there will just be an entry for [submodule "htap"]
>> in the newer version, without anything that links the old one with
>> the new one), how would the mapping inside $GIT_DIR know?
>
> It depends. Maybe git-mv could have rewritten the internal mapping
> as well.

And then after doing the "git mv" you have pushed the result, which I pulled. Now, how will your "internal mapping" propagate to me?

I also do not think "this is similar to file renames" holds water. Moving the path a submodule bound to from one path to another is done as a whole, and it is not like the blob contents where we need to handle patch application that expresses a move as creation and deletion of similar contents at two different paths. We can afford to be precise (after all, we are recording other information about submodules by having an extra .gitmodules file).

In short, "name" is not a design mistake at all. That needs to be excised from the "background story".