[tux3]

Oh, I have practically the same alias.

You might be surprised at this if you use Git in append only mode, making "fix 1", "fix 2", ... commits on a branch when you find a problem in a previous commit

Another workflow is to keep each commit self-contained, rebase the series when you make changes, and send the v2, v3, ... of your pull request with push --force

Of course, if you do this on a shared branch that other people also want to commit on, you may want to pick a desk close to the exit, and far away from any windows

[aunderscored]

Have you considered fixup commits? On shared branches they work very well. Either autosquash before pushing, or as part of your final PR prep

[tux3]

On shared branches I prefer to send pull requests, that way I can rework my draft and respond to review comments until it's ready, without pushing undercooked commits directly on the shared area

What lands on the shared branch has a meaningful history, that has helped me more than once to understand the context in which an old change was made, when running git blame many months later.

I feel like it should be as easy to review the history as it is to review a PR. Squashing makes this a bit harder for me. Especially when autosquash loses long commit messages.

But I like to use git-absorb to automatically create fixup commits, it generally works pretty well and saves me a little bit of tedium each time!