Re: Notes on Using Git with Subprojects

Shawn Pearce wrote:

 - Higher level projects should drive subprojects.

   Higher level projects tend to be composed of specific revisions or
   specific generations of subprojects.

   Part of the content of the higher level project is just what
   those subproject specifications are and how those subprojects
   should appear in a working directory.

I used the term "generation of subprojects" as not everyone wants
to bind their root project to a specific revision of a subproject.
Indeed that may not be entirely practical.  Instead just a particular
lineage of development (e.g. "Version 1.0" vs. "Version 1.2")
may be all that is needed.

Does it not make sense that a commit of the higher level project should 
include the contents of its subprojects at that particular moment in time?

e.g. using the previous example of a kernel, apache, glibc, etc

You may track the subprojects using whatever scm applies to THAT 
subproject. But when you want to record the state of the entire project, 
you want to include the state of the subprojects. So, your super-project 
commit would actually recurse down into the working directories of the 
subprojects and record the state/contents of each file that makes up 
each of the subprojects.

So, if someone is tracking the overall project, and they do a pull of 
v1.1 (tag), they will see exactly what v1.1 looked like in your repo.

What this makes me think is that it might be useful to have a mechanism 
for recalculating the tree-ish of a subdirectory and finding an 
associated commit, for the case where a subproject is also managed by git.

i.e. given a super-project in this state, and knowing that this 
subproject is managed by git, which revision of the subproject are we 
talking about, and can we find a commit that matches this tree-ish? 
(assuming we have the history of the subproject available, of course)

Regards,

Rogan