Page History

Turn Off History

GIT Trac

These are some working notes of the process for adding a new ScmTrac. Eventually they'll be usable or, at least, coherent.

Steps to add GIT support to CVSTrac (#476):

What The?

http://git.or.cz/

Strictly speaking, GIT isn't an SCM. Close enough.

First Steps

Getting something to work

The file /cvstrac/git.c is going to be where most of the action is found. Start by going through and removing stuff that the GIT code won't use. Rename all the various required functions to "git_".

Once we get the cosmetic stuff out of the way, we basically have to start in on git_history_update(). This is called periodically to find new changes from the repository. Practically speaking, this means it's going to get called and will need to efficiently say "show me any changes since revision n", for some n, and then suck in the changes into the CHNG, FILE and FILECHNG tables in some way that makes sense to the end user. How the filesystem is represented to the user has little bearing on CVSTrac, so go with something "natural" for GIT users. What we care about the entries in the CHNG table which should, as much as possible, look like atomic changesets. That should be feasible for any SCM more modern than CVS.

The first thing that has to be dealt with in git_history_update() is how to handle git's concept of HEADS. Unlike CVS and Subversion, there's no concept of a linear "list of changes" that covers all repository activity. At least, I can't find one. For each "head", however, it's possible to trace everything back. The catch, however, is that we're walking back down a tree and a certain number of commits in each list are going to be shared between different heads and that AFAICT it's not possible to determine from the revision history which "head" is what, in CVS or Subversion, we'd call the trunk. In other words, while git most certainly supports a rich concept of branching, we can't reliably name any of the nodes in a git tree.

In the short term, this means we're going to ignore the whole issue of git branches.

Once past that issue, the actual procedure for pulling git revision information out is trivial. git was designed for having stuff like this built around it and it really shows. The lack of an easy way to diff blobs is a bit odd, but otherwise things just work the way a C coder would want them to.

We should also look at handling git tags. Not sure how we want to manage that.

Cosmetic Details

Code like:

  if( !strcmp(g.zSCM,"cvs") ){        
  }        

is found in various places. You probably want to look around and either disable certain functions which aren't relevant for GIT or enable certain functions which are applicable but aren't used by all other SCMs.

In the case of git, the user-file things (like CVSROOT/passwd) aren't ever going to be used. In addition, it might be worth thinking about how changesets/revisions/hashes are displayed since, quite frankly, the usual unintelligible 40 character alphanumeric strings aren't pretty to look at or compact to lay out.