logoalt Hacker News

ahartmetz • yesterday at 11:35 AM • 1 reply • view on HN

No, you wouldn't. git rebase -i is to remove noise, which is about merging commits that, well, make more sense together than apart. Which is mostly about summarizing trivialities (e.g. several typo fixes) and squashing fixups into commits that introduced a problem in the same branch.

A typical bugfix branch might look like this after rebase -i:

Move property to a more appropriate place

Improve documentation of feature Foo

Fix accidental O(n^2) in feature Bar

Fix interaction of Foo with Bar

Replies

skydhash • yesterday at 12:00 PM

Those looks more like noise to me. A squashed merge (or a final squash before PR) would be:

  TN 43 - Fix mismatched interface between Foo and Bar

  We've moved the X property to a more appropriate place and
  improved the documentation for Feature Foo. We've also found and fix
  an O(n^2) implementation in feature Bar.
The the ticket TN-43 will have all the details that have lead to the PR being made: Bug reports, investigations, alternative solutions,...

The commit message is what's more important. I don't think I've ever needed what is in a merged branch. But I've always wanted the commit at one point to have tests passing and a good description of the patch. And all the talk in the engineering team are always about ticket. It does makes sense to align those.

➕ show 1 reply