Re: gitpacker progress report and a question

["Eric S. Raymond" <esr@thyrsus.com>]

Felipe Contreras <felipe.contreras@gmail.com>:
> I believe that log file is much more human readable. Yet I still fail
> to see why would anybody want so much detail only to import tarballs.

The first time I needed such a tool (and I really should have built it then) 
was during the events I wrote up in 2010 the INTERCAL Reconstruction Massacree;
full story at <http://esr.ibiblio.org/?p=2491>  Note in particular the
following paragraphs:

    Reconstructing the history of C-INTERCAL turned out to be something of
    an epic in itself. 1990 was back in the Dark Ages as far as version
    control and release-management practices go; our tools were
    paleolithic and our procedures likewise. The earliest versions of
    C-INTERCAL were so old that even CVS wasn’t generally available yet
    (CVS 1.0 didn’t even ship until six months after C-INTERCAL 0.3, my
    first public release). SCCS had existed since the early 1980s but was
    proprietary; the only game in town was RCS. Primitive, file-oriented
    RCS.

    I was a very early adopter of version control; when I wrote
    Emacs’s VC mode in 1992 the idea of integrating version control
    into normal workflow that closely was way out in front of current
    practice. Today’s routine use of such tools wasn’t even a gleam in
    anyone’s eye then, if only because disks were orders of magnitude
    smaller and there was a lot of implied pressure to actually throw
    away old versions of stuff. So I only RCSed some of the files in
    the project at the time, and didn’t think much about that.

    As a result, reconstructing C-INTERCAL’s history turned into about two
    weeks of work. A good deal of it was painstaking digital archeology,
    digging into obscure corners of the net for ancient release tarballs
    Alex and I didn’t have on hand any more. I ended up stitching together
    material from 18 different release tarballs, 11 unreleased snapshot
    tarballs, one release tarball I could reconstruct, one release tarball
    mined out of an obsolete Red Hat source RPM, two shar archives, a pax
    archive, five published patches, two zip files, a darcs archive, and
    my partial RCS history, and that’s before we got to the aerial
    photography. To perform the surgery needed to integrate this, I wrote
    a custom Python program assisted by two shellscripts, topping out at a
    hair over 1200 lines of code.

The second time was much more recent and concerned a project called
(seriously) robotfindskitten.  This code existed as a partial CVS 
repository created by someone other than the original author,
and some disconnected tarballs from before the repo.  The author
has requested that I knit the tarballs and the CVS history (which
is now in git) into one repository.

In both cases the object was to assemble a coherent history 
from all the available metadata as if the projects had been using
version control all along.

I know of at least one other group of disconnected tarballs, of a
program called xlife, that is likely to need similar treatment. It's
not an uncommon situation for projects over a certain age, and there is
lots of code like xlife dating from before the mid-1990s waiting for
someone to pick up the pieces.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>