Request for rebaseif extension to be provided by default with rebase

Sune Foldager cryo at cyanite.org
Tue May 24 11:34:21 UTC 2011


On 2011-05-24 13:31, Martin Geisler wrote:
>Sune Foldager <cryo at cyanite.org> writes:
>
>> On 2011-05-24 10:59, Marcus Lindblom wrote:
>>
>>> This is a feature that helps the user separate new functionality from
>>> the integration step of said functionality, and prevents information
>>> loss if manual intervention is needed to combine these two pieces of
>>> data.
>>
>> Yes, that it prevents information loss is a good thing; this is why we
>> wrap hg rebase at work to backup the original changesets in a bundle
>> first, so you can easily start over.
>
>That should actually not be necessary any more since rebase should
>backup the relevant changesets itself. Also, until repoman is made
>public, it doesn't help the rest of us :-)
>
>> But this is a meta-problem, that rebase should solve... e.g. by taking
>> backups and such. There is also hg rebase --abort.
>
>Right, rebase does keep the original changesets around so that you can
>abort it. But if the rebase is done, then there is no information left
>in the graph about steps the user took to resolve conflicts, if any.
>This is the information that Marcus would like to save.

Right... it's just annoying when the conflict turns out to be trivial, as
they often do, and then you're stuck with an extra merge-changeset which
doesn't really clarify anything and just clutters :p.

What would be nice, maybe, is a way to back-convert a merge of a single
changeset, into a rebase :). Of course with multiple changesets, this
can't really be done, but the more changesets I have, the more I generally
lean towards merging instead as well.

-Sune



More information about the Mercurial mailing list