Announcement

Collapse
No announcement yet.

GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by jntesteves View Post
    By the time he finishes, git itself will have been superseded by something with a much superior design. Possibly pijul.
    git will be around for decades due to the network effect.

    Plus, even though people in tech love to mock mom and dad and grandpa and cousin Jane for refusing to learn Linux, shell, etc... the truth is that far too many people inside the tech industry fought like hell against the move from CVS to SVN, fought like hell against the move from SVN to git, and will fight again when git is superseded. It doesn't matter whether the replacement is an improvement, they just don't wish to learn something new when they're comfortable with something they already know.

    Comment


    • #22
      Originally posted by AndyChow View Post
      Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.

      I maintain my original comments about reposurgeon. It's worth the wait.
      Have you seen reposurgeon code? https://gitlab.com/esr/reposurgeon/b...er/reposurgeon A cursory look shows:

      * The entire thing rests in a single 14K LOC file. Very hard to navigate.
      * 8-10 levels of nested ifs and fors.
      * Variable names such as "r" and "v" that give you no clue wtf they are.
      * Wheel reinvention such as "class Date(object):"

      This code is _nasty_, it is write only, hardly "worth the wait" IMO.

      Comment


      • #23
        Yeah, why aren't they just tossing out 20+ years of commit history, what a mystery.... Perhaps it's because GCC isn't just some fly-by-night toy project, and they care about being able to properly bisect issues later on? I also reject this idea that "rarely updated portion of GCC" means "unimportant part of GCC to users".

        Comment


        • #24
          Originally posted by paulpach View Post

          Have you seen reposurgeon code? https://gitlab.com/esr/reposurgeon/b...er/reposurgeon A cursory look shows:

          * The entire thing rests in a single 14K LOC file. Very hard to navigate.
          * 8-10 levels of nested ifs and fors.
          * Variable names such as "r" and "v" that give you no clue wtf they are.
          * Wheel reinvention such as "class Date(object):"
          You're looking at the old Python one. The new one has 21K LOC.

          But yes, I've looked at some of the code, and see no issue.

          Comment


          • #25
            Originally posted by AndyChow View Post

            You're looking at the old Python one. The new one has 21K LOC.

            But yes, I've looked at some of the code, and see no issue.
            Here is the go version
            https://gitlab.com/esr/reposurgeon/b...reposurgeon.go

            * 21K LOC in single file. Why not split this into multiple files? having files larger than 500 LOC is already a smell, 21K is very hard to navigate.
            * very high cognitive complexity. There are functions there that go 8-10 levels of nested ifs and fors. Should be refactored into multiple functions

            That said, the code does look better. He no longer have such massive functions and he names his variables better.

            Comment

            Working...
            X