• EmergMemeHologram@startrek.website
    link
    fedilink
    arrow-up
    9
    ·
    10 months ago

    At least a squashed merge I can drive all the chances with git blame, instead of focusing out what “format” that touched the whitespace on 3 lines is masking.

    • pixxelkick@lemmy.world
      link
      fedilink
      arrow-up
      18
      ·
      10 months ago

      Downside: you can only have 1 single person be blamed for the squash. If multiple devs worked across multiple commits, you have to squash it down and pick just 1 person who’s name shows up for git blame, which can actually be a pain.

      Ive already had cases where 2-3 months later I start getting pinged about changes to files I have never touched, only to realize my name is on it because I approved and triggered the final PR squash merge so like 4 devs worth of commits have my name on them, and I have zero clue which dev did which change or why, so it’s all squashed together.

      It’s not even about bad code for “blaming”, but we have changes where the question is “why did we do this? Was it for an important reason?” and I have to go “I dont fuckin know, I know my name is on it but it was one of who actually did it and we have now entirely lost the git history on who actually did it so you’ll have to ask everyone and hopefully someone remembers why it happened…”

      No. Thanks. Git rebase interactive is the only way to go, maintains git history and keeps everything clean, and its not even that hard to use if you use a sane IDE like lazygit or git extensions.

    • beefsquatch
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      Agreed, I see that as a win. Easy to revert a whole branch/PR