Re: Notes on Using Git with Subprojects

[A Large Angry SCM <gitzilla@gmail.com>]

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.