On Tue, Feb 14, 2017 at 1:56 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> 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.
Maybe it would work similar to a rename detection
utilizing a bloomfilter that includes all recorded sha1s at a given path
and then we can take the sha1 from the a given path and check for each
absorbed submodule git dir if that commit belongs to this repo.
I did not quite think it through, but I was pointing out this is brittle.
I guess a quick way would be to follow the .git file inside the submodule
if that exists and if not build up an internal cache that can map
"path -> potential git dirs".
Of course we can argue that the same problem applies to e.g. remotes:
If I have
remote.origin.url = git://kernel.org and
remote.mirror.url = kernel.googlesource.com
then swapping the urls will of course yield different behavior
for 'origin' and 'mirror'. But in this case it is obvious because
"origin" is not the same string as "kernel.org".
So long term, maybe we should come up with a better default name
for submodules, e.g. just a hash of say the URL being used when
adding the submodule.
> Don't
> forget that name was introduced as the identity because we cannot
> assume that URL for a single project will never change.
Yes, URL and path can both change over time, which is why it is
a good idea to have them versioned as well as having a way to
overwrite the URL in the config later on.
> I fully agree that our documentation and user education should
> stress that names must be unique and immultable throughout the
> history of a superproject, though.
This would be a good paragraph in this "background story" that this
patch tries to write. I'll add that.
Thanks,
Stefan