[eru]

Making those provisionally merge commits (and testing them) is a good idea, if you can spare the computational resources.

See https://bors.tech/ for a similar idea.

What I would object to is changing the 'official' master every few minutes automatically.

[jaggederest]

Yes, I would not advocate for that either. I like having PRs be a more complete thought, ideally, though sometimes you're left with 3 PRs for "one change" if you need e.g. a database change, a migration for the data, and changing the code to use the new column, which is frustrating but doable.

[eru]

I'd like my PRs to tell a very sanitised story of how I could have come up with the change, with the power of foresight.

Basically, first you write your code however you see fit. Then you use git to rewrite history to make the reviewers life easy, and then you give it to the reviewer.

The reviewer doesn't need to know that my original version had a bug that I fixed later. I can make it look like I came up with a bug free version from the start.

[jaggederest]

I used to do that but these days I prefer the whole story be in there so I can reference it later if I run into the same bug in a different place.

In general I find my past efforts to maintain a clean git history were probably not that useful, as long as you're not running e.g. 4 or 5 branches in parallel with crossing history. Branch off, make change, merge back main, PR, is fine.

[eru]

Most of the time most PRs are small and can be squashed into a single commit, and still produce useful history.

Sometimes it makes sense to have multiple commits. The next step up the complexity ladder is:

- one preparatory refactoring commit that does _not_ change behaviour

- one simple commit that changes behaviour