Re: Subprojects tasks

From: Alan Chandler <alan@chandlerfamily.org.uk>
Date: Dec 17, 2006, 08:48 UTC
Message-ID: <200612170848.10092.alan@chandlerfamily.org.uk>
In-Reply-To: <7vzm9nelob.fsf@assigned-by-dhcp.cox.net>

On Saturday 16 December 2006 18:32, Junio C Hamano wrote:

Show 18 quoted lines

> Because I am primarily a plumber, I was thinking about the
> changes that need to be done at the plumbing level.  I only
> looked at the prototype when it was announced, and I do not know
> the progress you made since then.  Could you tell us the current
> status?
>
> I am assuming that the overall design is based on what Linus
> proposed long time ago with his "gitlink" object.  That is,
>
>  * the index and the tree object for the superproject has a
>    "link" object that tells there is a directory and the
>    corresponding commit object name from the subproject.  Unlike
>    my previous "bind commit" based prototype, index does not
>    have any blobs nor trees from the subproject.
>
>  * the subproject is on its own, and can exist unaware of the
>    existence of its superproject (there is no back-link at the
>    object layer).

I have been following the submodules (subprojects - is there any difference?) discussion from afar, getting lost quite frequently in what is actually being discussed and why. I don't think the idea I express below has been mentioned, but apologies if it has.

One element I felt has been missing is a vigorous discussion of what submodules are for and what are their use cases. The "submodule is on its own" issue seems to have crept into the discussion - but there was one use case that was discussed, where some actually help by the submodule could be useful.

The use case was when the supermodule wanted to make use of the header files of the submodule because it was using the submodule as a library.

This did make me wonder if the submodule should not export some form of "approved" set of content (or files - and I do think care is needed here as to which it is when we think about renames) which is both

a) a subset of the full tree that is stored at commit time, and b) does itself have a commit history

(I am clearly thinking that would be the standard "include" files, but not the actual source of the library - (but it might include the library it self as a prebuilt binary library?)

This does suggest it is a tree object stored in the repository - and that it is linked in time via a set of commit objects - I'll call them the "export commits". I am not sure whether a new commit should be made everytime there is any change (via a normal commit) to this content, or (and I slightly favour this) there is a new commit made which is somewhat akin to a tag when the project wants to release a new version of its interface.

Supermodules, which then made use of that library would, the do some form of shallow clone, shallow in the sense that it only pulled in the exported commit content and also (possibly) shallow in the sense that it does not need to go back in time to get old versions of the exported commit.

-- 
Alan Chandler