To get a commit history that makes sense. It’s not supposed to document in what order you did the work, but why and how a change was made. when I’m knee deep in some rewrite and realize I should have changed something else first, I can just go do that change, then come back and rebase.

And in the feature branches/merge requests, I don’t merge, only rebase. Rebasing should be the default workflow. Merging adds so many problems for no good reason.

There are use cases for merging, but not as the normal workflow.

Your real commit history is irrelevant. I don't care too much about how you came to a particular state.

The overall project history though, the clarity of changes made, and that bisecting reliably works are important to me.

Or another way; the important unit is whatever your unit of code review is. If you're not reviewing and checking individual commits, they're just noise in the history; the commit messages are not clear and I cannot reliably bisect on them (since nobody is checking that things build).

I write really poopy commit messages. Think "WIP" type nonsense. I branch off of the trunk, even my branch name is poopy like

feature/{first initial} {last initial} DONOTMERGE {yyyy-MM-dd-hh-mm-ss}

Yes, the branch name literally says do not merge.

I commit anything and everything. Build fails? I still commit. If there is a stopping point and I feel like I might want to come back to this point, I commit.

I am violently against any pre commit hook that runs on all branches. What I do on my machine on my personal branch is none of your business.

I create new branches early and often. I take upstream changes as they land on the trunk.

Anyway, this long winded tale was to explain why I rebase. My commits aren't worth anything more than stopping points.

At the end, I create a nice branch name and there is usually only one commit before code review.

I don't want to see any irrelevant history several years later, so I enforce linear history on the main branch in all projects that I work on. So far, nobody complained, and I've never seen a legitimate reason to deviate from this principle if you follow a trunk based release model.

why would you lose commit history? You are just picking up a set of commits and reapplying them. Of course you can use rebase for more things, but rebase does not equal losing commit history.

I think that only the most absolutely puritan git workflows wouldn’t allow a local rebase.

The sum of the re-written changes still amount to the same after a rebase. When would you need access to the pre-rebase history, and to what end?

Because gerrit.

But even if i wasn't using gerrit, sometimes its the easiest way to fix branches that are broken or restructure your work in a more clear way

really; keep reading about all the problems ppl have “every time I rebase” and I wonder what tomfoolery they’re really up to

If it is something like repo for configuration management I can understand that because its often a lot of very small changes and so every second commit would be a merge, and it's just easier to read that way.

... for code, honestly no idea