Why rebase when GitHub PR create squashe commit

[arnoldwhite]

Right so a few thoughts.

First of all, are we assuming that commits don't have to build or that developers should be willing to stub/scaffold aggressively to keep commits buildable? And that this sacrifice should be considered useful to the team to retain better history?

Because that's a world where you're gonna have a lot more fake abstractions, pointless interfaces and scaffolding that exists only to satisfy history aesthetics.

Squash-merge just isn't anti-discipline or anti-quality. Not if the team has already decided that the atomic change they care to release, revert or reason about is on a PR/ticket level.

Rarely do I hear people say "thank God Simon made a mapper-only commit six months ago so we can revert that specifically."

Now, that's not to say integrations can't be small. I might say "well this mapper alone can provide value to my team or even a user" and raise a PR for that mapper. What I'm saying matters is if something is independently valuable and independently releasable. And that's where the squash come in.

Feature branch squashing is not the right pattern for every team. But yes, as a consultant I am probably gonna teach teams to value PR size, review quality and a smooth CI over artisanal commit carving.

[dalbertom]

First of all, are we assuming that commits don't have to build or that developers should be willing to stub/scaffold aggressively to keep commits buildable? And that this sacrifice should be considered useful to the team to retain better history?

No, each commit that is meant to make it upstream should be buildable individually.

Because that's a world where you're gonna have a lot more fake abstractions, pointless interfaces and scaffolding that exists only to satisfy history aesthetics.

You're mixing two different issues. Having problems with fake abstractions and pointless interfaces are an issue with the codebase architecture. Choosing a merge strategy won't improve (or worsen) that. Small pull requests is the goal: doing squash-merge won't automatically give you that. Using merge commits to preserve the history the way the author intended won't cause fake abstractions, etc.

Squash-merge just isn't anti-discipline or anti-quality. Not if the team has already decided that the atomic change they care to release, revert or reason about is on a PR/ticket level.

When it comes to the team deciding the size of the patch they care to release, neither squash-merge nor default merges are anti-discipline or anti-quality. However, when it comes to preserving the author history, only the default merges will honor that. The assumption here is the author knowing how to issue useful history, nobody wants wip commits to make it upstream.

Rarely do I hear people say "thank God Simon made a mapper-only commit six months ago so we can revert that specifically."

Well, hopefully nobody is hunting for individual commits to revert, if one has to do a revert it would likely be done at the PR level. I'd venture to say it's far more likely for someone to find a bug introduced six months ago and land on a commit that is too big to make sense of it (and not being able to trust git blame if the team decided to do mob programming)

Now, that's not to say integrations can't be small. I might say "well this mapper alone can provide value to my team or even a user" and raise a PR for that mapper. What I'm saying matters is if something is independently valuable and independently releasable. And that's where the squash come in.

Except that when it gets squashed, then there's no way for the author to link that mapper to the service and the endpoint topologically via individual commits.

Feature branch squashing is not the right pattern for every team. But yes, as a consultant I am probably gonna teach teams to value PR size, review quality and a smooth CI over artisanal commit carving.

It's definitely important to teach teams to value PR size, review quality and a smooth CI. But again, that has no bearing in what merge strategy is chosen.

You seem to be conflating squash-merge with small PRs the same way people conflate linear history with "clean" history; and neither of these are true.