Fixing rebase rather than avoiding it

[Óscar Fuentes]

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

> Ó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.

Revision 2 is identical to revision 1.1.1

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

It is not necessary that you come with scenarios where merging makes
sense. This is about scenarios where rebasing makes sense.

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

So, why don't record everything that was once typed while editing the
files? Because it would create an amount of information which, although
valuable in theory, would be an incovenience in practice. Too much
supposedly useful information is bad, because it is in the way when you
go after the really useful stuff.

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

So I should put on the commit message of the merge revision something
like "there is nothing interesting to see on the merged history" ?

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

The first workflow that was recommended to the Emacs developers creates
a merge for every change, even for the most trivial ones. Fortunately,
most people migrated to saner practices. Those who still are using the
initial workflow (because they learned it at the beginning and didn't
cared about looking at other options) are polluting the history with
unnecesary merges that just contribute to make bazaar slower on the
Emacs repo.

rebase saves a lot of time too by allowing to commit several small but
independent changes on the same branch and pushing them upstream on one
batch. This is a generalization of the case you call "degenerate" (which
is too common on projects that reached certain development stage.)