Chris Cruft

Git is da bomb, written by The Man, all the kewl kidz sing its praises.  The Rails community has dropped Subversion like penicillin on clap.   And I’m really looking forward to taking advantage of the distributed nature of Git.

But I have existing projects that use Subversion, including projects that represent Rails plugins.  Plugins are indispensable when working with Rails and probably a bajillion other frameworks, tool sets and such use them to compose independently developed code.

Too bad, then, that Git’s support for composed projects sucks.  It cannot match the simplistic yet effective behavior of svn:externals.  At least for me, Subversion’s externals do the following Good Things:

• Records my project’s dependency on external plugins, either to a specific version or the latest version (edge) of that plugin.
• Supports transparent commits to my project’s code with no regard to fact that there are external plugin dependencies.
• Supports transparent commits to a plugin’s code with the same tools and commands as changes to my project’s code -this can be valuable if you use plugins to factor your own common functionality into a self-maintained plugin or if you are a contributor to plugin project.
• Transparently promulgates macro operations on my project code base to the plugins, i.e. one can checkout my project and get updates on my project with no concern that it is composed of plugins.

Git can do some of this through submodules -but there are holes.  I’m far from competent with Git, but just trying to setup a Git project with submodules seems to have these issues:

It’s not possible to track the latest version of a submodule.

And while there are tools that attempt to address the problem, I’m left with the nagging feeling that this is a fundamental design flaw or a limitation from the distributed nature of Git.  Anyone?  Anyone?