Felipe Contreras <felipe.contreras@xxxxxxxxx>: > 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> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html