[keybored]

Three options? The best alternative to squash-merge is to freely rebase before you merge. Or for that matter squash if you just end up with one commit (because rebase subsumes squash).

1. You get rid of WIP commits, typo fix commits, all kinds of transient changes (for review and so on)

2. You keep the substantive ones

3. All changes are logically separated

I don’t see where you cover this option.

> Also setting the commit message in main to the `{title} (#{prNum})\n\n{prDescription}` format preserves all the good context from your PR and lets you get back to it if you need.

Again. It is ironic that people are so comfortable with dumping the history in a webapp when you are working with a version control system.

I am fine with a lot of the history being on GitHub or whatever other webapp. The review history, that is. But I’m not comfortable with leaving the history of the pre-squashed commits on GitHub if those pre-squashed commits were useful for the long-term history.

[kccqzy]

If the code author deems the pre-squashed commits useful, they would've split their PR into multiple PRs. I personally do this all the time: each PR has only one commit, but PRs can depend on each other.

And if the PR author deems their commits insignificant, they can feel free to make one PR and they squash & merge.

[keybored]

This is like a game of tag. We move on from the squash policy to a different weird requirement.

Vanilla tools make PRs have a certain overhead. Dependent branches and flipping from the terminal or IDE to the webapp and so on.

And these vanilla tools are often a team requirement. But with git(1) you can work around all that overhead.

Am I gonna stop weirdly insisting on using the version control system itself for version control instead of latching onto whatever passes for “PR”? Apparently not.

[kccqzy]

Only people who aren't good at git will think dependent branches are overhead.

The version control system itself doesn't have enough features for collaborative coding. It doesn't have all the discussions and messages exchanged between authors and reviewers. The main task here isn't version control itself but a collaborative social process. The kernel has LKML. The rest of us mostly use GitHub. By making one large PR with distinct commits you force that discussion to be intertwined together. That's why I continue to believe the best way is to make multiple smaller PRs each with one commit (or multiple commits that are squashed upon merge).

[keybored]

> Only people who aren't good at git will think dependent branches are overhead.

[redacted]

You have to create branch names and keep them in synch. with `git rebase --update-refs` constantly. But worst of all: vanilla forge PRs don’t support it. So you have to thread these dependencies manually instead. What magic eliminates this overhead?

[kccqzy]

I really don't understand you here. Yes you do need to run `git rebase --update-refs` constantly but you want your commits to be meaningful enough to be preserved, you are doing the rebase anyways. If you don't want to type `--update-refs` put it in your .gitconfig. And what do you mean vanilla forge PRs don't support it? If it's GitHub you simply tell your reviewer to look at the commit diff view not the PR diff view.

[keybored]

> Yes you do need to run `git rebase --update-refs` constantly but you want your commits to be meaningful enough to be preserved, you are doing the rebase anyways. If you don't want to type `--update-refs` put it in your .gitconfig.

I tried out that config for a while but it was too much of a sledgehammer in practice. It rewrote things that I didn’t want.

> And what do you mean vanilla forge PRs don't support it?

Hmm. This is what I would call support:

- Push one time and you get the option from the remote to generate X dependent PRs since the remote sees that you have some branch tip and X-1 ancestor branches which are not in `main`... etc.

I at least haven’t heard of this support in GitHub.

What does not rise to that level: having to create X PRs manually and making sure to target each of them individually.

But apparently the Git experts (or simply the ones who do not suck at it) do this with vanilla tooling. I could very well be missing something here.

> If it's GitHub you simply tell your reviewer to look at the commit diff view not the PR diff view.

You mean a five-commit PR could be a one-commit-per-PR by saying to the reviewer “look at the commit diff”? Then I have no trouble with it.

[keybored]

I thought that the Git pro would educate us who don’t know what we are doing on this topic.