[dapirian]

> As for squashing, I believe that everything should be rebased instead to maintain a proper, linear git history

Rebasing on your PR branches is up to you, it's subjective, but setting GitHub to rebase your PR commits onto your main branch as it's merge strategy is not proper at all. It might 'work' for a tiny hobby project, but it does NOT work for any kind of team activity / professional environment - it would be an immense amount of bloat onto your main branch, and git will eventually start to get slow as mud on every operation because of it. Fun fact, git performance does not scale linearly, and big monorepos hit this problem. Beyond performance, when looking through git history on the main branch: - Every commit on the main branch should map 1:1 with a reviewed PR that passed CI tests/checks - The 'mapping' can just be done by having the PR number in the commit message title. GitHub does that for you with the settings in this blog post - It's not uncommon that someone has 30+ commits on their PR branch, many of which are in a totally broken state, have blatant typos, etc. People just don't (and it's not even desire-able for them to) structure their local commits while working on a PR to be some kind of iterative working state that is useful for others to look at. It's beyond clutter to have these 30 broken commits with crummy commit messages like "update" rebased onto the main branch for all to see for all time.

[dukedylan]

Not necessarily real world, considering performance especially. Let's say that a project is smaller, git improves performance, or computers get more efficient:

Regarding commits relation to PRs: GitHub still maintains this with rebase and merge. It's linked in the UI when viewing any individual commit on a branch.

Broken commits are mitigated by testing each commit incrementally.

Commit messages must be reviewed and edited to make sense. Having 30 commits would be something flagged in review. It's okay and encouraged to make a bunch of commits during review and then require those to be rebased into logical, atomic commits prior to merging.

[dapirian]

If each of your commits are tested and make sense independently, they should be different PRs - sounds to me like you're just smashing 5 stacked PRs into 1 with highly fussy curated commits, which aren't guaranteed by github settings to each be passing CI

[dukedylan]

PRs are just logical groupings of commits. It makes it efficient to group related commits together. You are correct that each of the commits could be separate PRs which is part of the advantage to this pattern—code contribution is always atomic and easily organized. How you organize these contributions is done whichever way makes it easiest to get merged in efficiently.

[thunky]

I think the parent's point is that if you only just choose to think of the PR as the "unit of change" on your software product, rather than commits, all of this extra discipline you're imposing on yourself just goes away.

And what do you lose by making this decision?

The main branch, being the only place where the changes really matter, can still capture all of the necessary details of the changes (based on the PR) in the commit message when it's merged. This is the point where the curation is most useful, and where it's easiest to apply and apply standards, run tests, and actually enforce that they're followed.

[dukedylan]

> all of this extra discipline you're imposing on yourself just goes away.

I think the extra discipline is just shifted to the PR in that case instead of the commits. What's lost is the ability to make code contributions of related changes together in a PR which can be more efficient than making many small PRs.

[thunky]

The extra discipline I'm talking about has to do with curating the commits in order to make them meaningful. Here's an example of this from the wild:

https://github.com/BurntSushi/ripgrep/pull/350#issuecomment-...

BurntSushi (the project maintainer) didn't care about the story the commits told, he cared about the entirety of the changes being made to the repo (at the PR level).

> What's lost is the ability to make code contributions of related changes together in a PR

You're considering each minor commit to be an independent code contribution. BurntSushi instead considered the PR to be the code contribution. The code changes are the same either way you look at it, and there is a single PR in both cases, so it's a matter of choosing your perspective.