Re: Notes on Using Git with Subprojects

From: Shawn Pearce <>
Date: 2006-09-28 10:36:58
Rogan Dawes <> wrote:
> 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?

If the subproject is a Git repository we can simply record a commit
SHA1 or a tag SHA1 and assuming we can locate the objects for that
repository in the future we can fully recover that subproject.
No subtree tracking necessary.

If the subproject is an SVN repository we can simply record
the branch/tag path and the specific revision number and fully
recover that subproject, assuming we have access to the central
SVN repository.  If we don't or we are concerned about that then we
would want to use git-svn/git-svnimport to mirror the SVN repository
and treat it as a proper Git subproject.

If the subproject is a Monotone or Darcs project I believe we could
also store some small token for a unique directory state of that
subproject and recover that from Monotone or Darcs without importing
the entire subproject into Git.  If you don't trust Monotone or Darcs
then maybe you should be importing/mirroring that project into Git.
At which point its a proper Git subproject.

If the subproject is CVS then you either need to trust the CVS
tag or import the tree into Git.  If you are going to import the
tree into Git then you might as well just treat the subproject as
a proper Git subproject and use some sort of CVS import or mirror
to keep that in sync.


My basic point here is that a subproject already has its own SCM
and if its not Git you probably either are going to convert it to
Git via a Git bridge (git-svn anyone?) or you are going to keep it
in its "native" SCM as you probably don't want to incur the disk
costs of storing it twice (once in its native SCM and once in Git).

So subtree tracking is probably unncessary.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at
Received on Thu Sep 28 10:37:24 2006

This archive was generated by hypermail 2.1.8 : 2006-09-28 10:38:10 EST