3 ms·

If you don't rewrite history in git, I don't want to bisect in your repos. If you push rewritten history to master, you're a git. Conclusion: learn your tools

• mkesper 1y ago
  The modern workflow is just to let GitHub squeeze yor shit commits into one and then rebasing that.
  • baq 1y ago
    Hardly anything modern about it, but it's a way of keeping a somewhat sane history. Certainly better than merging 'fix' 'fix' 'fix comments' into master. The thing is, we could have done better (and have been) since before git even existed.
  • cmrdporcupine 1y ago
    There are legit reasons to have a series of commits within one PR, and rebase and merge them as is, and use amend/fixup and force pushes to maintain them cleanly. It's not my favourite process, but...
  • vvillena 1y ago
    The "squash everything" mantra turns git commit history into a series of snapshots devoid of any logical notion about how code evolves. Squashed commits are strictly worse than plain, non-fast-forwarded merges from rebased branches.
    • baq 1y ago
      Depends on your commits. If it’s untested noise I’d much rather they’re squashed so bisect doesn’t meander in trash.
      • vvillena 1y ago
        Bisecting with --first-parent takes care of this.
• spookie 1y ago
  Not a single soul besides the one rewriting history knows what they're in for after the fact. It's a recipe for disaster. Unless you mean squashing commits, which I don't consider rewriting history, just a retelling of the fact. Still, it's something one can only do very sporadically, or at known periods of time. I 'm sure others would be more pedantic about it and this wasn't clear above.