Re: Subprojects tasks

[Jakub Narebski <jnareb@gmail.com>]

Alan Chandler wrote:

> 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. 

In the absence of sparse/partial checkout, and it's use in submodule
support, this can be solvd purely on porcelain level.

You would have to simply maintain separate 'includes' branch, similarly
to how 'html' and 'man' (and 'todo') branches are maintained in git.git
repository -- it would be your 'set of commit objects'. Then the only
think that would be needed is some commit / post-commit hook which would
examine if commit touches "include" files and if it does, make a commit
in the 'includes' ('inc' for short) branch.

Suportmodule would then use either 'master' branch for full sources,
or 'includes' branch for headers only.

P.S. Cc: Alan Chandler <alan@chandlerfamily.org.uk>, 
Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git