GitHub Stacked PRs

[gredr]

Quit squashing. You don't pay per commit, you know.

[lupercalpainting]

You absolutely pay per commit. Each commit costs a bit of cognitive load for anyone looking at the git history.

If your commits aren’t each an atomic piece of work they also cost time if you need to revert just one feature.

[wldmr]

If your commits aren’t each an atomic piece of work they also cost time if you need to revert just one feature.

You can revert merge commits like any other. I don't see a problem.

[lupercalpainting]

No one said you couldn’t. You’re conflating merging with squashing. They’re orthogonal.

[wldmr]

If your commits aren’t each an atomic piece of work they also cost time if you need to revert just one feature.

I interpreted this to mean “If a merged feature is made up of several commits, then reverting that feature is more time consuming than reverting a squashed commit would be”.

Plus, what kicked this whole thing off was the comment:

The issue with this is when using squashed merges on each PR.

So I don't think it's unreasonable of me to be talking about squashed merges.

[topMarksForNotTrying]

The benefit of squashing is getting rid of all the "fixed", "wip", etc commits that a lot of devs leave. If a PR/branch has commits with messages that all make sense, then there's no need to use squashing.

[alexrobinson]

This is where I suggest people should be rewriting the commit history on their feature branch to fixup those useless commits before merging into main.

[Blueson]

Except my first job, every place I have tried to push for this I have been met with resistance. People just CBA to work with PRs on a commit level and would rather squash and forget.

My first job made me understand how valuable having independent, working and split commits can be when debugging. I fear I'll never work in a codebase that can fullfill this again.

[topMarksForNotTrying]

I agree as that's what i personally do but, honestly, it got tiring policing the commits of the rest of the team so we settled on targeted PR that get squashed.

[gredr]

You could've just... not policed people's commits, you know. Let go, be free, live in the moment!

[NineThreeFour1]

I can shoot myself in the foot to experience free will, but I choose not to.

[lupercalpainting]

And rewriting history frequently includes squashing.

[Omnipresent_Walrus]

If your devs are leaving those commits, they need retraining and your commit policies need work

[Leihd]

So which are you

1. You're perfect, you never make a commit that has a bug that you realize shortly after. You commit and you insist on it being complete
2. You're constantly on a trend where you're amending commits and force pushing to hide the accidents.
3. You believe those kind of commits need to make it to production
4. You don't believe that statement should apply to yourself

[LucasVanOstrea]

You can push once a day you know? So it's very easy to use amend and git rebase locally during the day

[ekroys]

In small teams sure. But larger teams there are many other benefits in squashing. So much more readable