Yeah learned this the hard way.

  • Eiri@lemmy.ca
    link
    fedilink
    arrow-up
    1
    ·
    9 hours ago

    Why would you want to squash? Feels weird to willingly give up history granularity…

    • smiletolerantly@awful.systems
      link
      fedilink
      arrow-up
      1
      ·
      7 hours ago

      Because a commit should be an “indivisible” unit, in the sense that “should this be a separate commit?” equates to “would I ever want to revert just these changes?”.

      IDK about your commit histories, but if I’d leave everything in there, there’d be a ton of fixup commits just fixing spelling, satisfying the linter,…

      Also, changes requested by reviewers: those fixups almost always belong to the same commit, it makes no sense for them to be separate.

      And finally, I guess you do technically give up some granularity, but you gain an immense amount of readability of your commit history.

      • Eiri@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        1 hour ago

        Huh. Never thought of it that way. I was never bothered by a long commit history at all. Search and filter tools in the git client always get me where I want.

        The one issue I have is when there are way too many extant branches and the graph takes up happy half my screen.

        But that’s more of a Fork issue than it is a fundamental one. The Fork dev could conceivably find a solution for that.

        Either way, I guess I see what you mean. I’m just not that strict about commits. Commits just for the linter aren’t a thing since we have a pre-commit hook for that, and typo-fixing commits… Well, they happen, but they’re typically not numerous enough that I’d find them to be any sort of issue.

        As for whether I’d really want to revert a particular change – while I work, yes. Afterwards, I see what you mean; i could probably squash 50 commits into 15 or something. But when I think about the time investment of reviewing every commit and thinking about how they ought to be grouped together before making my merge request… I have a lot of trouble convincing myself it’s a good time investment.

        Maybe I’d think otherwise if we had a huge team. We have maybe 10 devs on this project at any given time.