[noirscape]

My personal preference is merge but using the --no-ff flag. That way you get all the advantages of a rebase (since all your original commits are rebased into the target branch) but you also get a merge commit to confirm that all those changes were a part of the same set of patches.

That can often help a lot to figure out why something ended up the way it did, but you also don't turn your entire history into a flat pile of disparate commits.

[Groxx]

Yeah, I do kinda like this setup too. You can have both readable (rewritten) history and structured sub-commits for "a change" rather than a totally flat stack. Plus I don't care about your local history, but I do care about the final history.

It's definitely how I prefer to review code (big changes broken up to isolated portions that are easier to validate, and the whole thing at once so you don't get lost in the trees), so it's how I would prefer to read it later too.

It does still have merge commits where stuff can hide though :/ and you've got to remember --first-parent :/ and all not-merge-focused things so have problems with it :/