News for hackers. Stuff that matters.
Re:Two Years of Squash Merge (2019) by finnh on Friday April 30, 2021 @03:35PM (#26998230)
Spot-on for both counts. Preserving a PR's individual commits in the master branch is insane - many of those commits won't represent a fully working system anyway, so why keep them in master?
Re:Two Years of Squash Merge (2019) by gouggoug on Friday April 30, 2021 @08:13PM (#27001385)
It's entirely not insane _on the premise that the history is clean_. That's the whole argument that is being made here.

If you think that "Preserving a PR's individual commits in the master branch is insane - many of those commits won't represent a fully working system anyway", your issue _is_ "that your commits don't represent a fully working system anyway", _that_ is what you need to fix.

You need to make sure your history _does_ represent multiple small digestible atomic chunk of codes, that are understandable individually.

By squashing, you're not fixing the root cause, you're treating the symptoms.

Re:Two Years of Squash Merge (2019) by sjoruk on Friday April 30, 2021 @03:50PM (#26998417)
> many of those commits won't represent a fully working system anyway

This is entirely within the control of the developer(s) working on the project. Whether it's worth it is up to the people working on it. It's certainly not insane though - it's much easier to fix merge/rebase conflicts when each commit is small and easy to reason about.

Re:Two Years of Squash Merge (2019) by finnh on Friday April 30, 2021 @05:05PM (#26999323)
> it's much easier to fix merge/rebase conflicts when each commit is small and easy to reason about.

I agree, but I'd say it in the context of PRs. It's much easier to fix issues (and avoid them) when _PRs_ are small & easy to reason about.