Re: Notes on Using Git with Subprojects

Rogan Dawes wrote:
[...]

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)

Some development environments will require that all the (used) code is 
imported into the local VCS of choice. But not all environments. For 
some development environments, recording the version of the subproject 
is sufficient. Assuming it's possible at some future time to get the 
state associated with the version.

Also keep in mind, to effectively participate in a project, you will 
likely need to use the VCS of the project. So importing everything into 
another VCS (Git) will just cause _you_ more work.