Re: [RFC] Submodules in GIT

[Andreas Ericsson <ae@op5.se>]

Uwe Kleine-Koenig wrote:
> Hella Andreas,
> 
> Andreas Ericsson wrote:
>>>> The only problem I'm seeing atm is that the supermodule somehow has to 
>>>> mark whatever commits it's using from the submodule inside the submodule 
>>>> repo so that they effectively become un-prunable, otherwise the 
>>>> supermodule may some day find itself with a history that it can't restore.
>>> One could circumvent that by creating a separate repo for the submodule
>>> at checkout time and pull the needed objects in the supermodule's odb
>>> when commiting the supermodule.  This way prune in the submodule cannot
>>> do any harm, because in it's odb are no objects that are important for
>>> the supermodule.
>> Yes, but then you'd lose history connectivity (I'm assuming you'd only 
>> pull in the tree and blob objects from the submodule, and prefix the 
>> tree-entrys with whatever directory you're storing the submodul in).
> That's the reason for me prefering to pull in the complete commit.
> 
> I don't understand what you mean with "prefix the tree-entrys with
> whatever directory you're storing the submodul in".
> Maybe one of us doesn't understand tree objects correctly.  AFAICT they
> don't store the location where they occur, so there is no need to store
> a prefix.  E.g. 
> 
> 	100644 blob 610bafd79f92c7e546b104d5b22795df1f099723    Makefile
> 	040000 tree 754eadab39642175748bb02155d2959176bcf014    subdir
> 
> So the tree that only contains the Makefile specifing LD_FLAGS has the
> sha1id 754eadab39642175748bb02155d2959176bcf014 independent of being the
> root of my project or a subtree.
> 
> But maybe I misunderstood you?
> 

Nopes. I just didn't think of the fact that subtrees are trees and never 
store any path-info no matter what. So basically the supermodule can 
store all trees of all submodules for each commit adding a new submodule 
revision (which is neat, since "casuals" never have to bother with 
getting all the submodules if they want to see all the code used in any 
particular revision), while we invent the new tree object "subm" that 
points to a commit in the submodule repo. We then teach the tools to 
recognize when the *real* submodule repo is present and just don't check 
out trees from the supermodule odb that lead us to directories where 
submodules reside. Simple and beautiful. Me likes.

*IF* we teach the history viewers about submodules is a different matter 
though. I'm not sure it would make much sense to have simple text-mode 
browsers show the submodule history, although I can imagine qgit and 
gitk wanting to take advantage of their nice side-by-side DAG displaying 
code to show all the repos in parallell, or link between them in some 
point-and-click kind of way.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se