3 ms·

a 40yo code base. Eeeek!

• chris_wot 2y ago
  No, a 40 year old codebase with only 25 years of commit logs. And the initial commits during the Sun releases are insane - they took a bunch of commits, mashed them together and then added them as a single commit with a log message stating what all the commits they munged together did. Nightmare fuel. Excellent lately though.
  • doubled112 2y ago
    Sounds like my personal git repos. God help us all if I ever need to share them, but I doubt it.
  • ianburrell 2y ago
    The squished logs sounds like what Subversion does with merges. OpenOffice looks to have used Subversion for a while.
    • chris_wot 2y ago
      Yeah, I think they did something like this.
  • mlyle 2y ago
    Honestly, though, looking more than 10 years back in revision control is usually only for curiosity. Whatever historical reasons existed for code to be a certain way are likely impenetrable or no longer relevant.
    • iforgotpassword 2y ago
      Nah, I've often found the opposite to be true. Granted, it requires proper commit messages and code comments, but I've had my fair share of "oooh I see" moments when I encountered nonsensical crazy code. Sometimes it reassured me that it could safely go, other times it revealed a whole new dimension nobody was really aware of anymore that then got a good chunk of comment space in the code base.
      • mlyle 2y ago
        Well, it really requires: A) great commit messages, B) comments that are worse than the commit message so that you have to go scavenge in revision control, C) a single or very few commits where the craziness happened, and D) a codebase that hasn't drifted enough that this signal is hard to find. I've had poor luck spelunking for reasons in things like the Linux kernel. 90% of my revision control effort looks at things from the past couple of years, and before then it rapidly becomes diminishing returns.