• bloopernova@programming.dev
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 year ago

    It’s pretty easy to set up, and gives you an added way to verify that the code in your repository is supposed to be there.

  • Sigmatics@lemmy.ca
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    It’s nice and all, but in a GitHub/GitLab PR workflow world, your commits are mostly squashed and rewritten by the remote, so it doesn’t even show up on main

    So there’s really only a benefit if you don’t use squash and bother with maintaining proper commit messages in your PRs

        • Kevin Lyda@programming.dev
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          I have never heard proper reasoning for squashing commits. I don’t think sanitized history is useful in any context. Seeing the thought process that went into building something has been repeatedly useful in debugging things. It’s also useful to me as a software engineering manager to help folks on my team get better. I could care less how “pretty” git log looks, but I care a hell of a lot about what git diff and git blame tell me. They help me figure out where issues actually are and how they came to be.