Fixing rebase rather than avoiding it

[Ben Finney]

Óscar Fuentes <ofv at wanadoo.es> writes:

> 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?

The changes that were actually made on that branch, in distinct
revisions as they were made and viewed by the person committing them.

The merge may have made other changes before being committed; those,
too, need to be separate for future forensic purposes.

Each one of them represents a working-tree state that existed on disk
before being committed. That's valuable, because one can then
*reproduce* those working-tree states and see what the person who
committed them was looking at.

> 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?

Who's making that assumption? The merge revision (revision 2 in your
example) shows an aggregate of all the changes in the merge. The
subordinate revisions are available for closer inspection if needed.

> At least `rebase' has the advantage of not having to write the commit
> message again.

Only for the degenerate case where the merge pulls in only one foreign
revision. I maintain that's a small price to pay for a guarantee of
lossless tracking of the revision data.

-- 
 \          “Computer perspective on Moore's Law: Human effort becomes |
  `\           twice as expensive roughly every two years.” —anonymous |
_o__)                                                                  |
Ben Finney