Dear Git project,
We really need a working, uncluttered sparse checkout feature. With Subversion, CVS, and numerous other version control systems, I used to be able to store multiple subprojects in a single large repository, so I’d have a setup like this:
foo-incorporated/
→foo.com/ # Foo's web site
→app1.foo.com/ # rails app
→app2.foo.com/ # some other app
which would allow me to build a single system composed of multiple related apps, guarantee the relative directory structure of those apps, and then publish to production with a single command. I could also decide to work just on an app:
svn checkout /svn/foo-incorporated/app1.foo.com/trunk app1.foo.com
and put that working copy in my local web-served directory (~/Sites on Mac OS X), and then access http://localhost/~me/app1.foo.com to see my running app.
With git, however, if I want the same workflow, I have to maintain foo.com, app1, and app2 in separate repositories entirely, or else the local URL becomes http://localhost/~me/foo-incorporated/app1.foo.com. Then, when I want to work on app1 I have to descend an extra directory level to get there. It also means I can’t easily rely on objects defined externally. I could use git submodules, but that would require maintaining a “collector” repository with nothing but submodule definitions alongside the separate repositories for each subproject.
This gets really bad when projects get large but are still related. Then git’s sparse checkout could give me several levels of depth before I get to the one small piece of a project I really care about. The git solution seems to be to create new repositories to solve this problem, but it’s really much simpler to deal with a profusion of folders in a hierarchy than it is to deal with a profusion of repositories.
I’m really missing the strict separation between working copies and repositories that I had with Subversion and CVS. Please let me have it back.
Thanks,
Scott
