Hacker News Reader

Comment by skydhash | Hacker News Reader

If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket.

A ticket should be atomic describing a single change request. PR in this case are the working room. It can be as messy or as clean as you want. But the goal is to produce a patch that introduces one change. Because if you would rebase -i at the end, you would have a single commit too in the PR.

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

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.

They aren't noise at all and have found them useful a bunch in the past when I worked at a place that didn't squash. Commits at this level act as immutable comments that don't get out of date. Provided you do --no-fast-forward merges, the merge commit is the feature commit and you can get the "clean" feature history with `git log --merges --first-parent`. Best of both worlds! Being able to `git blame` and get a granular message about why something was done can be really handy, especially when looking unfamiliar code.

I get where you came from, but I prefer having a more holistic view of a change, especially from a product perspective. So even when git-blaming, either I’m reading the current file or I go straight to the log of the commit (with message and diff).

I prefer granularity at a product or team level decision. Not workflow details.

I'm not trying to convince you to adopt or anything, but I'm saying you can have all of that without squashing with the caveat that you would need an alias to jump to the merge commit. Otherwise, you just treat merge commits as you would a squash one. Merge commits are just like regular commits that can have a custom message and show a diff.

> If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket.

With GitHub you can squash any PR merge. The link to the PR will include the complete history of the feature branch prior to the merge. Even the commit history prior to force pushes is tracked.

Reply on news.ycombinator.com