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.

Be warned that I'm a complete git newbie so some of the details of how git actually works make be incorrect.

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 repository file tree is represented to the user really doesn't affect 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 up a tree from its leaf nodes and a certain number of commits in each list are going to be shared between different heads. AFAICT it's not possible to determine from the revision history which "head" is what, in CVS or Subversion, we'd call the trunk. git does have a concept of HEAD, but it's more of a working concept similar to CVS's "sticky" tags. 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. Obviously, those aren't displayed in git mode.

In addition, it's necessary to adjust how changesets/revisions/hashes are displayed since the usual 40 character hexidecimal hashes make a hash of our layout code and aren't meaningful in most situations anyways. We handle that by creating a printable_vers() function to turn something like:

   1190649aaff433501d6e6c92deb8a0f201fdd8d0 

into just

   1190..d8d0 

Isn't that better?