Request for rebaseif extension to be provided by default with rebase

[Martin Geisler]

Sune Foldager <cryo at cyanite.org> writes:

> On 2011-05-23 15:54, Marcus Lindblom wrote:
>
>> Of course, changes in separate files are not always safe to reorder
>> either, which is why merge is the safest default, since you have two
>> commits which both work (i.e. tests pass and all that) and you can
>> see how they were merge and test if the merged version is correct
>> too.
>
> I don't see how merge is safer than rebase. You only have two
> changesets that work if you merged correctly, just as you only have a
> changeset that works after rebasing, if you rebased correctly.

Merge is safer since it keeps your old (working!) commits around after
the merge. That is the whole point: a merge is an explicit combination
of changesets and keeps more information for the future. If the merge
turns out to be bad, then you can go back to the original two changesets
and re-merge them (and maybe one day mark the bad merge as abandoned).

A rebase is implicit: you lose the information about how conflicts were
resolved. That is a big feature in your hands since it removes clutter,
and a liability in the hands of others because it removes information.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/