Request for rebaseif extension to be provided by default with rebase

[Sébastien Deleuze]

@Adrian : perhaps the default rebaseif behaviour should be modified
from internal:merge to internal:fail in order to be more conservative
by default. Not sure wich one is the best. From my point of view, the
key point is to avoid uneeded merge when there is absolutely no
conflicts between local and remote.

On Mon, May 23, 2011 at 4:58 PM, Martin Geisler <mg at aragost.com> wrote:
> 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/
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>