Fixing rebase rather than avoiding it

[Óscar Fuentes]

Ben Finney <ben+bazaar at benfinney.id.au> writes:

> Óscar Fuentes <ofv at wanadoo.es> writes:
>
>> Rebase is useful for keeping a linear history, when it is right to do
>> so. Too often a merge is just useless noise.
>
> That's mixing up separate concerns.
>
> If a person finds the merge information to be noise, the tool should
> support that (as Bazaar does with its ‘--levels N’ option, which
> defaults to hiding merged revisions).
>
> There's no need to *remove* the data from the history, and lots of
> reasons to want to keep it: consistency with other branches sharing an
> ancestor, tracking down just what happened when necessary, knowing that
> every revision represents an actual working tree state that was
> committed, etc.

See this piece of history:

2 Fix bug #234 (merge)
1.1.1 Fix bug #234
1 Whatever

What valuable information is provided by revision 1.1.1?

You can argue that it is hidden by default (and this is a nice feature
of bazaar that I miss on git) but how do you know that the merged
history adds nothing without looking at it first? You can suggest `merge
&& revert --forget-merges', but isn't it a poor's man `rebase'? At least
`rebase' has the advantage of not having to write the commit message
again.