Yeah learned this the hard way.

  • Eiri@lemmy.ca
    link
    fedilink
    arrow-up
    1
    ·
    5 hours 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.