Hacker News Reader

Comment by alphazard | Hacker News Reader

Most developers I've worked with think of Git as a CLI front-end to GitHub. They aren't writing commits with the intention of showing their work, they are using commits to save their work before signing off, or to trigger CI. They aren't proficient enough with Git to go back over these and clean them up, as would be expected in a project like the Linux kernel.

If that's the state of developer proficiency with version control then, ideal workflows aside, we need a way to prevent those noise commits from ending up in master, and the easiest way is to squash with every pull request, as part of the "merge" automation.

View on HN

Why do you need to squash & merge literally every PR? Why not use squash & merge when appropriate and rebase & merge otherwise? That's what I do for my projects. Most contributions coming from others tend to get squashed & merged, where as I'll rebase & merge my commits. But I'll sometimes rebase & merge PRs from other contributors who have broken their change down into thoughtful commits.

This is it. The real answer to this whole debate is "it depends" but for some reason that doesn't seem to satisfy people.

The effective management approach (in opposition to the limp-souled "servant leader" anemia) is to make decisions for your team to eliminate stupid work.

What, you're going to let anyone waste time on tabs versus spaces?

You've presupposed that this is all about stupid stuff in the first place. Moreover, mixing tabs and spaces for indentation leads to sadness. But squash and rebase are perfectly compatible with over another.

Programmers sometimes have to decide stuff. That's okay.

> Why do you need to squash & merge literally every PR? Why not use squash & merge when appropriate and rebase & merge otherwise?

"When appropriate" is the key here. That's asking people to make a decision, take on additional cognitive load, which does not have a clear deliverable or success criteria. In practice the default is what happens.

We need to make decisions about code and maintainability all the time. I don't see why this is any different.

Every opportunity to eliminate cognitive overhead is a win for the team.

As I say to my children on the reg, "What's the best way to clean up a mess? Don't make it in the first place."

As my children repeatedly prove: one person’s “not a mess” is another person’s disorganized chaos.

Telling my child not to make a mess so he can avoid cleaning it up would not be an effective tactic at anything other than acting smug.

You're presupposing that this decision is worth making for programmers in the first place. I don't see why that ought to be true.

Reply on news.ycombinator.com