3 ms·
> 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 ol
by AceJohnny2 11y ago
> 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 https://www.openhub.net/p/emacs
Here, look at the first few:
http://git.savannah.gnu.org/cgit/emacs.git/log/?ofs=124080 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=ce5584125c44a1a2fbb46e810459c50b227a95e2 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 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.
- bhaak 11y agoI see your 1985 date and I lower it with this https://github.com/Vanilla-NetHack/NetHack/commit/a1b94f052fdd1bd4464c6725c755606c307b334f 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.
- lmm 11y agoI 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)
- bhaak 11y agoBitKeeper 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.
- marcoperaza 11y agoSomeone ported and grafted the old history onto the current history: https://archive.org/details/git-history-of-linux https://archive.org/details/git-history-of-linux You can even pull from the current linux repo.
- bhaak 11y agoYeah, 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 https://github.com/torvalds/linux/commit/1da177e