If you have a nasty nasty difficult to find bug that emerged some time ago, and your history is littered with merge commits, git bisect is going to go badly. If your history is linear, and your data model is compatible with itself across history for the bits you're interested in, and you can write a sane test case - auto or manual, then your troubleshooting is going to be O(n^x) simpler than the case where you've got merge commits, and save you many hours. Not something I have to do often (once a year or less really) but valuabable enough that it's important to me nonetheless.

Rewriting history when things land in develop/master I think is a good thing. To use an analogy from the humanities, history is written by the winner.

At work we're collaborating with the merge camp at the moment and it's very difficult to work out what they're doing from reading their history - some of it is their bad practices elsewhere, but the merge commits are confusing.

I'd also be fine with no rebasing but any merges must be fast forward, so if you can't do that fix your problems prior to integration.

Also I've used a few different approaches for a few different projects, and the rebase/squash merge approach is the one that in my experience makes things clearer and easier to understand. I'd be reluctant to return to other approaches (aside from enforcing fast forward merges in public branches).

I believe that squash merges are a good compromise as so long as you don't mess with the reflog and keep the automated parts of the commit messages, then there is no lying about history.

Gotta say, in 20+ years of branching and merging using CVS, SVN and then Mercurial, I've never had an issue tracking down nasty bugs. Maybe git bisect on a linear history would hypothetically be a few minutes faster in some cases, but doesn't make it worth all of the extra work and the dangers of overwriting other people's work.

I think the Fossil devs also make a good case that the problem is really a limitation in the tools like git bisect.

Intentionality is the perfect argument against merging feature branches: I intentionally don’t want my half-broken commits to be in the production branch. I want the complete product to be there.

> I intentionally don’t want my half-broken commits to be in the production branch.

That makes no sense. What does it matter that interim versions from a merge might not work, what matters are the milestones like merges and tags. Basically you're imposing a silly aesthetic restriction on what's supposed to be a functional tool.

The whole argument feels a bit People's Liberation Front of Judea to me. On the other hand I do have strong views on the matter, and I am pretty certain that my views are pretty close to the correct ones.

My silly aesthetic restriction is ‘tests pass’ and my branch commits don’t have this quality in all cases.

Apparently what you do makes sense for you, but I hope you realize that using interactive rebase you can turn your half-broken commits into nice and clean commits!

I try to do this as I go, but there is always a "history review and fix if necessary" stage after I've got the code I wanted and before merging.

Apart from having granular, reviewable, bisectable history, there were many a time when by having this extra look at the code I found bugs or design flaws.

Whether such effort is worth it for you, and whether you have time\energy\discipline\skills for it is a different question.