[bonzini]

The individual commits disappear if the branch or repo used in the pull request are deleted.

[ktross]

GitHub actually keeps these in the pull request indefinitely if you delete the branch. You can also restore the branch at any time if needed. We have the branches set to automatically delete when a PR is merged.

[bengale]

When I’ve done this before the commit messages get listed in the squash commit.

[bonzini]

The list is useless, it's the contents that are helpful when debugging (and the wip commits just get in the way).

[MereInterest]

Exactly! Suppose feature A is implemented (commit 1). Then it is discovered that the original implementation breaks feature B, and that is resolved (commit 2). In merge workflows, you have a merge commit on main, while commit 1 and 2 are maintained. In rebase/squash workflows, you have a single commit on main, with both changes. If 6 months later I find that the commit broke some feature C, I really want to know if it was the main change or the compatibility fix that did it.

[bonzini]

Right, though usually commit 2 would be placed before commit 1.

[MereInterest]

True, and that's a better way around it, since then both commits can run and pass the tests.