Cherry-picking is harder. Splitting up the branch is harder.

I cherry pick occasionally. I don't see how it's affected at all? Edit: If another dev and I both cherry pick the same commit concurrently, that might do something weird. Maybe that's it?

I don't know what splitting up a branch means.

Let's say I'm working on a feature branch, and end up realizing I should really be opening two PRs because this one PR is going to be two hard to review. It's much more difficult to reorganize commits on your feature branch if you have merge commits from the main branch mixed in with your changes. If there was merge conflict resolution along the way as well - good luck making sense of things.

Merge commits 'lock' you in to the commits you've made so far.

Merges I create from the CLI don't really look that differennt from the ones through some forge UI PR process. I don't know what Linus is getting at. If I was working under someone who had a process like this, I could ask them to clarify what they wanted me to do. I don't have that. And I need to be able to justify all of my decisions. So this isn't useful to me.

I don't doubt that Linus has good reasons for all this. I just don't know what they are. And I don't know if they're applicable to other repos.

...why? Isn't this exactly what rebase is for? Just plain, boring, non-interactive rebase.

Yes this is exactly what rebase is for, but a lot of developers do the merge based workflow.

Maybe? But it's also what merge is for.

If I used rebase like this regularly it would become difficult to determine if a given commit is an ancestor of HEAD. Sometimes I like to do that.