Hacker News Reader

Comment by busbus | Hacker News Reader

May I ask you why you want to squash every branch ?

What is the size of the resulting commit (in terms of average modified files, lines of code) ?

I've shared this anecdote elsewhere but it's my go-to example. We recently had a new engineer join our team, we gave them a small piece of work related to a bigger feature we had completed months before they arrived. They tracked the feature back to the squashed PR commit, which of course referenced the Github PR URL- in there they had the engineer's summary and implementation caveats, the review comments from the rest of the team and the discussion context. They could reference all the commits made throughout the process from there. The PR itself used "Closes #X" syntax, so they could jump back to the engineering task and up into the product backlog item that spawned it. They nailed the change the first time :-)

> What is the size of the resulting commit (in terms of average modified files, lines of code) ?

Lately I'm starting to advocate squashing PR branches even if they have only a single commit. The real benefit here is that Github puts the PR URL into the squashed commit message. It automates the "context links" regardless of whether a PR branch ends up being 1 commit or 50

I understand the needs. But to me, I can’t see any real value to squashing other than cleaning local history before sharing the code. Also, and that’s important for me (maybe other people doesn’t care of it) I lose the ability to bisect more precisely. When I know that my guilty commit is a squashed one, I have to watch every modification to understand what went wrong, which takes time for me.

Also, everything you describe can be achieved with a merge commit. As a side effect, when you look at the history, you may be annoyed with small commits that may not interest you. But Git can help by displaying only merge commit (with --first-parent option).

Ah bisect is a great use case here.

True that you can achieve it in a merge commit. And I think Github includes the PR URL in a merge commit as well iirc. I suppose my main argument is really just that the always-rebase strategy that was trendy for awhile has some downsides over squash/merge commit /shrug

The merge commit also includes the link to the PR when merged via the GitHub UI (or locally via `hub merge $PR_URL`).

I don't think I understand what "squashing PR branches" means (a github feature I haven't noticed?), but:

> The real benefit here is that Github puts the PR URL into the squashed commit message.

While not in the commit message, github will show you the PR a commit is part of in it's commit view regardless, also for every commit in a PR whether it's one commit or 50. Which I do find invaluable for tracing the documentation of a change, agreed! Not everyone knows about this feature (I don't think it's been there forever) in github UI.

Eg notice the `#279` included in this github commit UI display (the PR was, I'm pretty sure, not "squashed").

https://github.com/traject/traject/commit/10339e774e92e57f44...

One typical reason would be easier history following and eventually revert.

Reply on news.ycombinator.com