Re: Notes on Using Git with Subprojects

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Right. Which is one of the truely wonderful things about symlinks in .git/refs and symlinking .git/objects. :-)

I don't know about anyone else but this thread has certainly helped me rationalize a few thoughts about "subproject" support.

The major things I've taken away from it are:

 - Subprojects of any reasonable SCM should be supported.

   Although this is Git we sometimes want to play nice with other
   people working in the same pond.  We have a historical track
   record of doing this when it makes sense (git-svn, git-cvsserver,
   etc.) but clearly doing it for every SCM out there is not
   possible.

   But that said having "out of the box" support for Git subprojects
   within a larger Git project should Just Work.  It doesn't
   really yet.

 - 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.

 - Git Porcelain should help the user.

   Git operations should translate down through lower level projects
   when possible, and lower level project changes should push up
   when possible.

   E.g. git-fetch in a higher level repository should percolate
   down into the lower level repositories automatically.  Ditto with
   git-checkout and probably git-push.  git-commit in a lower level
   repository probably should update the specification file(s)
   in the higher level repository but not commit the higher level
   repository.

 - The subproject SCM interface needs to be modular.

   Users need to include many different subprojects and not all of
   them use Git.  Ideally Git would be able to at least be easily
   taught by the user how to invoke a particular subproject's SCM
   for the purpose of an initial checkout, if not for additional
   operations such as pull, push, commit and tag.

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.

For example including a CVS hosted subproject into a larger Git project means you can't use a specific SHA1 to reference a single version of that CVS subproject. Yet you can use a CVS branch or label name. But both of those are moving targets in a CVS repository. But in a sane CVS project a label or a branch will be relatively stable over time, meaning that its good enough given that its all we got (without importing everything into Git anyway).

Likewise a Git project including a Git subproject should be able to reference a named tag of the subproject. If the subproject changes its tag and the fetcher agrees to the change (with a --force) then its OK for the subproject to follow that tag change. Likewise it should be acceptable for a subproject to reference a specific branch head. Although this is a moving target that may be acceptable while the higher level project is under rapid development.

However an annoted tag probably should not be able to be created on the higher level project unless all lower-level subprojects are referenced by tags (or the equivilant) in their SCM. Which implies using a "stable tag" in CVS, a "/tags/foo@rev" in SVN, or an annotated tag in Git and updating the specification file(s) to reflect that.