5 ms·

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 h

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...

zephod 11y ago
> 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?
- LukeShu 11y ago
  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.
  - paulddraper 11y ago
    Nonsensical, but still accessible
  - philh 11y ago
    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.
    - LukeShu 11y ago
      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.
  - Cyberdog 11y ago
    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.
    - wainstead 11y ago
      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).
  - zephod 11y ago
    But you could _delete it today_ and it would not be lost. Right?
- zephod 11y ago
  No idea why this was downvoted. Perfectly legitimate question given unclear circumstances.
AlexeyBrin 11y ago
How is Guile Windows support ?
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 ago
  I 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 ago

zephod 11y ago

> 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?

LukeShu 11y ago
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.
- paulddraper 11y ago
  Nonsensical, but still accessible
- philh 11y ago
  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.
  - LukeShu 11y ago
    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.
- Cyberdog 11y ago
  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.
  - wainstead 11y ago
    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).
- zephod 11y ago
  But you could _delete it today_ and it would not be lost. Right?
zephod 11y ago
No idea why this was downvoted. Perfectly legitimate question given unclear circumstances.

AlexeyBrin 11y ago

How is Guile Windows support ?

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 ago
I 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 ago