> but you don't throw away the feature branch history
Once a feature is merged, how is the history of a feature branch helpful?
Since I do not see/understand the benefits of retaining feature branch history, my preference is to squash commit and merge. Perhaps, this is a result of my habits that I carry from the ClearCase days, but would love to hear the downsides of this approach.
Well given that we're talking specifically about reverting the merge when something goes awry, firstly you want that history preserved so that you can re-start work on it, potentially without pulling in all of the changes in one go; and secondly so that you can determine the precise point at which the problem happened.
Consider the difference between:
* Well we need to revert this because it's causing problems, but now we've got one massive chunk of several day's work to pick through.
…vs:
* Well we need to revert this, but we can see that the problem was specifically commit xzy, so let's yank that, do it a different way, and merge the result.
Aside from that, it can be very useful to see the individual steps in implementing a feature for a variety of reasons. Given that a --no-ff merge achieves everything you are aiming for with the squash, why wouldn't you pick the more flexible approach?
Merge with --no-ff. You can revert easily, but you don't throw away the feature branch history.