Subprojects: a user perspective

["R. Steve McKown" <rsmckown@yahoo.com>]

We are looking to migrate from CVS to a distributed VCS like git.  I've read 
the discussions on this list WRT subprojects and wanted to present another 
user's perspective.  The history of this list is active, so I apologize if my 
post is redundant or unwanted.  Send flames my way!  ;^)

Our repository is relatively large and extensively uses the CVS vendor branch 
feature to use and track software components managed by other groups, such as 
the linux kernel, openssl, busybox, uclibc, etc.  These are the tasks that we 
perform to manage components:

1. Occasionally import new revisions of components we use into
   the component's private branch (like an incoming branch).
   This provides a version history of each component's "pristine
   source" as used within the project over its lifetime.

2. Each component gets a subdirectory in the project branch(es).
   Component versions are merged from the component's incoming
   branch into this subdirectory as new components or component
   revisions are incorporated into the project.

3. Local modifications, as necessary, are made to component
   code within the project branch(es), not the incoming
   branches which only hold pristine sources.

4. Patches of local changes made to a component, like for
   submission to the upstream maintainer, are built by diffing
   a project branch's component subdir with the component's
   incoming branch.

I think git can do all of this if the component incoming branches have the 
same path information as the project branches.  In other words, if the 
project places the busybox component at /src/components/busybox, then the 
busybox incoming branch must place the busybox code 
into /src/component/busybox.

So, in terms of adding specific support for subprojects, the only thing I see 
that could be improved would be the ability to reference a sub-tree in git 
operations that currently expect a tree (aka tree-ish or refspec parameters).  
I liked Junio's concept of subproject linking, but only because it provided a 
way to conceptually address a sub-tree.

With sub-tree addressing, a component branch could be naturally rooted, and 
diffing its head against the a project branch head at the component's subdir:

   git diff linux-incoming proj-branch@/src/components/linux

or merging a new linux version into the project:

   git checkout linux-incoming
   #suck in a new linux release from upstream
   git commit -a
   git tag linux-2.4.16
   git checkout master
   git pull . linux-2.4.16:.@/src/components/linux

All the best,
Steve