Re: gitmodules below root directory

From: Jacob Keller <jacob.keller@gmail.com>
Date: Sep 7, 2017, 01:25 UTC
Message-ID: <CA+P7+xrbmx7JaCfxKLwKqCTXVBMd4mSg8zpxDLqRoxVAJDwhtw@mail.gmail.com>
In-Reply-To: <xmqqk21b4n0k.fsf@gitster.mtv.corp.google.com>

On Wed, Sep 6, 2017 at 12:58 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> The current gitlink implementation records only the "what commit
> from the subproject history is to be checked out at this path?" and
> nothing else, by storing a single SHA-1 that happens to be the name
> of the commit object (but the superproject does not even care the
> fact that it is a commit or a random string).  We could substitute
> that with the name of a blob object that belongs to the superproject
> history and records the information about the submodule at the path
> (e.g. "which repository the upstream project recommends to clone the
> subproject from?", "what commit object is to be checked out").
>
> When you see a single tree of a superproject, you need to see what
> commit is to be checked out from the tree object and everything else
> needs to be read from the .gitmodules file in that tree in the
> current system, but it does not have to be that way.
>
>

IMO, this approach described here, (point the gitlink at a blob which describes the full contents, URL, etc) would make more sense. The trickiest parts I think are (a) it really requires tooling to change the git module vs just editing a file, and (b) we'd need to prevent the blobs from getting garbage collected.

I think it makes each individual submodule a bit more robust, since the actual submodule pointer always points directly to the full data about that submodule (it's recommended URL, it's path, etc), and changes to those things *are* changes to the submodule pointer.

Thanks, Jake