Hacker News Reader

Comment by Nelson69 | Hacker News Reader

It is possible, or even likely, that a repository switch could lose that history on a project like emacs.

Guile now has an elisp interpreter and guile itself has JIT capabilities as well as a number of other features elisp hackers have grumbled about over the years. It's been mostly one man's work but it has spanned years to get guile-elisp to where it is. The discussions about migrating to it have been somewhat interesting to read. You have a remarkably solid, cross platform, well tested product and they're very very cautious to harm that, even with big speed and feature improvements on the table. It's one of the few good examples of "maybe you want to think twice about fixing something that isn't broken." Then when/if they do fix it, I bet you'll be able to build it with the old elisp for 20 years, just in case something isn't quite right...

View on HN

> It is possible, or even likely, that a repository switch could lose that history on a project like emacs.

Emacs is, as far as I know, the project with the oldest history stored in git. It contains the first commit from April 18th, 1985. https://www.openhub.net/p/emacs Here, look at the first few: http://git.savannah.gnu.org/cgit/emacs.git/log/?ofs=124080 Because that link is likely to go obsolete as more commits are added, here's the first commit: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584...

That this commit even exists there is the result of 10 months of work by ESR, who perfected his RepoSurgeon tool on the Emacs repo, in order to cleanly pass over all the relevant commits and branches (and cleanup obsolete metadata from old version control systems). Here's one post about that work: http://esr.ibiblio.org/?p=5634

(as an aside, I think RepoSurgeon is a very interesting tool that operates on a git-fast-import operation stream, as invented by Keith Packard when he moved X.org to git. A git-fast-import stream is a wonderful VCS interoperable format)

Anyhow, my demonstrated point is: of any projects, I expect that Emacs is the least likely to ever lose history in a repository switch.

I see your 1985 date and I lower it with this https://github.com/Vanilla-NetHack/NetHack/commit/a1b94f052f... dated Dec 17th 1984. ;-)

Okay, this is not the official repository but one I did for us fork developers. And as we learnt last year, the NetHack DevTeam itself has been using CVS only since 2002 and apparently before that, they were just mailing around patches.

But of course you can set the date for any commit, so it's just a matter of finding someone who wants to have an accurate commit history and a project that is old enough. Especially with GNU projects, there are probably several candidates that would have a history starting in the 80s.

I was appalled when I learnt that Linus threw away the complete commit history of Linux when he switched to git. That was a veritable WTF moment.

I don't find it that implausible that the cost of preserving that history would have been higher than the value of doing so. (In Linux' case it would probably have meant writing an exporter for BitKeeper, which would have had to be done through reverse-engineering so as not to violate the license)

BitKeeper has an export command that at least exports diffs of its changesets. Merges would have probably been an issue to easily model.

But at least some of the commit history would have been possible to incorporate into the new git repository.

I'm no expert on BitKeeper, there were probably more options to achieve that but it seems Linus didn't think it was needed.

Someone ported and grafted the old history onto the current history: https://archive.org/details/git-history-of-linux You can even pull from the current linux repo.

Yeah, although git isn't really suited for stitching different repositories together.

git replace does work now somewhat better than git graft did but it shows that git was never meant to be used with multiple repositories.

Going by the commit message, Linus didn't see lots of harm by just cutting off the history:

  Linux-2.6.12-rc2

  Initial git repository build. I'm not bothering with the full history,
  even though we have it. We can create a separate "historical" git
  archive of that later if we want to, and in the meantime it's about
  3.2GB when imported into git - space that would just make the early
  git days unnecessarily complicated, when we don't have a lot of good
  infrastructure for it.

  Let it rip!

https://github.com/torvalds/linux/commit/1da177e

How is Guile Windows support ?

> It is possible, or even likely, that a repository switch could lose that history on a project like emacs.

Surely the "D" in DVCS means that many thousands of copies of the project history would be available around the world?

When the code was commented out, it would be several decades before Emacs would be switched in to a DVCS, then another 7 years from when the "please don't delete this" comment was added. Even if it was in the DVCS history, and there was a comment pointing to a commit ID, that would have been rendered nonsensical by the conversion from bzr to git.

Nonsensical, but still accessible

I'd be somewhat surprised if the bzr->git conversion did in fact mess those up. I was following ESR's blog when he was doing the conversion. He seemed to feel very strongly that the conversion should not mess things up like that. (His goal was that the history should look like it would have done, if people had always been using git.)

On the other hand, I'm less confident about the conversion to bzr. And anyway the relevant question is not "would it have broken?" but "did people have reason to expect it would break?"

And on the third hand, a commit id could be referenced by author and timestamp, which would be invariant under (competent) repo conversions.

The bzr->git conversion does look like it was always in git from a looking-at-the-repo viewpoint (sans commit messages mentioning RCS/CVS, et c.); but in-repo data wasn't changed much; when building from VCS, it sticks a VCS identifier in the version; prior to a certain commit the script for that tries to grab the commit ID from bzr instead of git. However, ESR's blog does suggest that commit hashes mentioned in the source were replaced; I'm not sure if that's true.

That said, referencing the commit by author and timestamp, instead of internal commit ID is the robust solution.

Did they not record the bzr commit IDs in the Git commit messages during the conversion? If they did, finding a Git commit that corresponds to a bzr commit ID should be trivial.

In a perfect world, sure. I once worked for a company that bought another company's assets (mainly the code base) and at some point in the past the code base had been migrated from CVS to Subversion and the commit history was simply lost. They probably just took a clean copy of the main branch and started a new repository. "Why was this written this way?" was not a question you could unearth from the repository, sadly.

(Another company I worked for had commit log entries like "I like cheese" so perhaps this company wanted to erase history for a reason. Here in the 21st century version control systems finally get the respect they deserve, though I bet there's a sad number of shops that still don't use one).

But you could _delete it today_ and it would not be lost. Right?

No idea why this was downvoted. Perfectly legitimate question given unclear circumstances.

Reply on news.ycombinator.com