Git scrutinized

There's a great introduction on git for SVN people like me, which made it twice as easy for me to look into how this thing works. Git only recently released their 1.5 version which is the first one that's supposed to be usable to the masses. (It might not yet be available pre-packaged for your Linux distribution, or available at all if you're running Windows, which could be a small hurdle at the beginning.) After reading the introductory couse and trying it out by myself, I must say I'm hooked.

For those who didn't know, git is the distributed RCS that was created by Linus and the other kernel folks because they needed to get rid of BitKeeper, and as the Linux kernel is a very demanding project both in code size and in patch management, git is quite capable indeed from an efficiency point of view. Currently in use by the Linux kernel itself, X.org, Wine, and One Laptop Per Child, to name a few popular projects.

As promised in my SoC application, here's a short rundown of features that are important to this abstraction layer.

Basics

Nothing missing here, and totally straightforward: by executing 'git command', you get all those nifty features like renaming, copying, removing, branching, tagging, reverting, committing, diffing, and yes, even merging. (The latter is very cool, as it not only obsoletes 'patch -p0', but also uses 3-way-diffs by utilizing the file history, in order to reduce or completely eliminate conflicts. And like 'git diff' or 'svn diff', it's completely client-side.) Commits are intuitively called "commits" (surprise!), and are identified by an SHA-1 hash of all the files contained in a commit. (Mercurial also uses SHA-1 hashes, probably a few other distributed revision control systems as well.)

Semi-off-topic: Thinking about (and looking up) revisions a bit more, it seems that CVS and Microsoft Visual SourceSafe - which shall be notoriously disregarded due to its scary feature set - that those two are about the only revision control systems that don't assign identifiers to a commit itself. So, as we really want to retrieve commit information just by looking up data from our {rcs_commits} table, I'd find it a good idea to also incorporate the revision identifier into this table. As a nullable column, so that CVS doesn't need to write data there.

Branching, tagging and file structure

Git does this quite similarly to CVS. Therefore, there's no prescribed or even recommoned repository layout like with Subversion where you put your data into trunk/, branches/ and tags/. Nothing new here, hardly worth a mention.

Authentication and hook scripts

Like SVN, git itself knows nothing of authentication but can be wrapped in ssh or https, and those manage authentication by themselves. As for controlling which branches and tags are being created, that can be achieved by server-side commit hooks just as well as the current CVS integration does it. Git offers a wide range of low-level commands which can retrieve all info you ever want to know about the current commit, and using those in the hook scripts does get you somewhere.

Distributed repositories

As expected, this is the major difference to traditional, client-server-centric revision control systems. The fact that git works in a distributed way means that everyone who works on the code carries a full copy of the whole repository, including the complete version history. As git stores both data and difference information in a ridiculously efficient way (in fact, git only stores data and extracts diffs out of that data), hard disk space isn't the great problem that you would think it is. It's even less a problem than it is for Subversion, because the latter stores all of your checkout uncompressed in hidden .svn/ folders, so that it can do serverless diffs.

So space is not really an issue here, not even with a still not too huge codebase like Drupal's. However, it's kind of tedious if you always need a full checkout of the repository, and that's what you get when you get ("clone") your initial checkout from the server. Imagine how you would need for all of contrib's modules, themes and translations if you just want to work on your two little pet projects.

Right, not cool. So best practice for git would mean to create a single repository for every single project, and instead of checking out the two paths where your pet projects reside, you'd get two complete repositories. This adds a new facet to our requirements, as it is now necessary to be able to manage hundreds of repositories, instead of just a few. Maybe even with automatic creation together with new projects. And of course, every single repository comes with its own set of hook scripts - granted, those could be symlinked if you want to centralize them.

(Mind that drupal.org is not going for git anytime soon, I'm just using it as a good use case.)

I also found out that the ominous reponame.git is not a file, but just a directory containing the current repository; the same thing that normally resides in the root of your working copy as hidden repo/.git/ directory. This is called a bare repository, and meant for public repositories on some server like the one that drupal.org provides. (Remember, repositories are otherwise meant to be carried around together with your own working copy.)

The coolest feature that comes with distributed repositories is certainly the flexible patch management facilities that you get by committing to your own local repository and only pushing it to the public one later. Or maybe fetching sources from someone else than the original server. In any case, those are arguably client-side and don't affect this project which is clearly aimed for the server.

In other news

I created two of the drupal.org projects that I'm going to need for my RCS modules, so that the database schema a.k.a. .install files are under revision control. Say hello to Revision Control API and Project RCS integration. Missing the actual module, but featuring .install, .info and README.txt files. I had planned to create a new "CVS backend" (short name: "cvs") project as well, but then came to me the reason why "cvslog" is not simply named "cvs" in the first place. Tricky stuff, I tell you ;-)

Proposals for the backend modules' naming scheme? How about "xxx_backend"? (Clean, but slightly ugly as this makes for a hook implementation which bears the sounding name cvs_backend_rcs_backends().) I can't currently think of any better solution.

I'm also playing with the idea of splitting out another module that would provide an interface (only optionally implemented by the backend) to "RCS Access Control", short name: "rcs_access". Which would also provide those motivation forms. However, I need this to rest for some time and decide later if it's necessary, it can always be split out from the CVS backend later on.

Upcoming work

Seems there are only two questions left since my previous post. And one of them is really marginal. Recap:

• Need a good solution on how to handle branches and tags. {cvs_tags} is not the ideal solution, given that branch != tag in most RCS. Neither can be attached to the commit itself, because it can potentially span multiple branches, including HEAD/trunk/whatever. (Which is not clean, but possible.)
• Is any extra care needed for directories? I think we can just treat them as files, like is standard on UNIX, but it's certainly possible that I'm missing something.

Before I head off to drafting the RCS API, I still want to take a look at Mercurial which seems to be a promising RCS as well. Maybe a short glance into Bazaar, too. And the need to answer the above questions is still there.