• 0 Posts
  • 7 Comments
Joined 1 year ago
Cake day: August 30th, 2024
  • Eiri@lemmy.catoProgrammer Humor@programming.dev•Well well well.
    1·
    4 days 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.

  • Eiri@lemmy.catoProgrammer Humor@programming.dev•Well well well.
    1·
    4 days ago

    That’s a good explanation of what it’s supposed to do. That was how I understood it as well.

    But anytime I’ve tried it, I’ve ended up with conflicts where there shouldn’t be (like, I already solved that conflict when I merged earlier) and/or completely undesirable results in the end (for instance, some of my changes are just NOT in the result).

    So I just gave up on the whole feature. Simpler to just merge the source branch into mine.