Copyright © 2016-2020,2022 by Thomas E. Dickey

Git-exports – comments


I have been tracking my projects using RCS since the late 1980s. I used SCCS for a few years before then. Developers who use my programs are accustomed to using patches and tarballs to track changes to these files, using their own procedures.

On the other hand, there are other people who would like to casually browse the source history. Not all of them are developers.

While I was working with XFree86, occasionally someone would ask where they could find a source-history for xterm and I would point to XFree86's CVS. I stopped committing to that in mid-2006. That finally became defunct in 2016 (ten years later).

Providing my own CVS (or whatever) web-accessible respository would take away development time and be expensive. On rare occasions, someone else would offer to do some part of this:

Git is a little more flexible than tar-balls:


Those were helpful, but did not complete the task. In the case of ncurses, those made web-accessible my weekly patches for ncurses starting with 5.6 (in 2006). During a given week, I make several changes, and the result is the weekly patch. Since most of the information would be omitted, I disregarded that.

Mawk seemed more promising. However, I ran into a few problems:

Because of these problems, the Ruby script (while interesting) was not useful. I could not use it on the larger projects, even for one-shot uses such as I did for mawk:


In May 2016, someone commented that there were several forks from my byacc tar-balls on github, and that was a problem. Actually, since none of the “forks” had been improved, there was little to discuss since there were no potential changes to merge back. In any case, I would merge into my RCS archives.

But that prompted me to think about just (as in ncurses) constructing a git-ball with the labeled revisions from my RCS archives. As of mid-November 2016, I had (using rcs2log):

Sedeño's git repository has about half of those labeled revisions: 48% in mid-November 2016.

I label things when I reach a milestone, whether or not that is when I decide to release a set of changes. By exporting the labeled revisions (rather than a complete archive), the result would still be useful, as well as being practical. But keep in mind that the number of labels is far smaller than the actual number of changes.

In my revised approach, it is possible to do incremental exports from the archive onto a git-ball. Exporting all of the labels in the ncurses archive takes hours; exporting the latest revision takes a minute or so.


I wrote a script release2git to do most of the work, and run that from a script r2g which knows how to manage the git-balls which I create and update. In some projects (such as xterm, the MANIFEST file is generated using the manifest script. That and other special cases are handled by release2git.

Not all of my projects had labels. I wrote another script tag-cutoff to label some of those using a cutoff-date. That worked for most, but not for the older vi-like-emacs archives which I received from Paul Fox in 1996. I labeled that by writing a custom script (like tag-cutoff) and used that to label those files.

I have generated git-balls for all of the projects which I share with others (as well as a few which I do not). You can see the result here:

While doing this, I realized that rcs-fast-export.rb would not be suitable, since using its approach none of the exported revisions would be signed. See the pgf-vile-snapshots repository versus the corresponding fast export for an example of this.

Scripts are a different matter. Those all live in common directories, from which I generate the tar-balls that you can download from my scripts page. I suppose that I could generate git-balls for those as well.

When I release changes to one of my projects, I do this:

The two steps use different keys, just in case.

Just as a reminder: these are snapshots. If someone wants to make a change, that will be done the same way as other projects, by first integrating into the RCS archives, and then exporting, updating the snapshots.

Other stuff

In a few instances, I work on programs which are only in Git:

In practice, updating a clone (using Git pull, merge, resolve, push) and applying changes back to the original repository (via a pull request) is just as much work as the process of exporting RCS to Git.