git-based release and distribution management for automake

[Roger Leigh]

Hi,

Last year, I wrote to the list to show an initial demonstration
of integrating automake with git version control.  This work has
been largely dormant since then, but over the last couple of weeks
I have completed an initial fully working implementation which may
be of interest to others.

The aim behind this is to increase the robustness of making
releases and to keep the actual distributed releases under version
control; normally while the sources are under version control, the
verbatim output of "make dist" is not since it's packed into a
tarball.  Downstream distributors may subsequently put that under
version control, but here it's done directly, skipping tarball
generation entirely.  Downstreams may now simply clone the
upstream repo and work directly with it; tarballs as a distribution
format may be omitted entirely.

Currently some projects make GPG signatures of their release
tarballs so that their integrity may be verified.  Here, we have
GPG signed tags which verify not only the distribution of a
release, but also its parent tagged release in git and all
prior history, providing a new level of integrity checking to the
release process.  Downstream changes can be traced all the way
back as well.

I've attached a Makefile fragment which can be included into your
top-level Makefile.am.  This adds three main rules:

• check-git: Checks that the working tree and index are clean, and
             that no untracked files are present.  This ensures that
             no files are distributed which aren't either under
             version control or generated by autoconf/make (and are
             therefore in .gitignore).
• release-git: Tags the current HEAD with an (optionally signed)
               release tag.
• dist-git: The main rule; injects $(distdir) onto a distribution
            branch and tags it with an (optionally signed)
            distribution tag.  This automatically calls the
            check-git and release-git rules and aborts if the
            tree is dirty or the working tree doesn't match the
            release tag.

There's also a dist-git-generic rule which skips some of the checks,
and is used to retrospectively inject past distributed releases into
git (and tie them to the release history).

The file contains documentation on the use of each rule and how
to customise for individual projects.

Any comments would be appreciated.  The terminology used may not
entirely fit with existing automake terminology (release vs
distribution), and could easily be changed.

Future work will add support for pristine-tar so that the distributed
release tarball can be recreated bit-for-bit identically to the
original directly from the distribution branch.


An example of what this looks like in a real-world scenario:
  git://git.debian.org/git/buildd-tools/schroot.git
Check out the distribution-1.4 branch (for example) and look at the
history with gitk to see how the distribution history ties up with
the release history and other branches in the repository.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

git-dist.mk
Description: Text document

signature.asc
Description: Digital signature