On Wed, Sep 6, 2017 at 12:58 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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
