Request for rebaseif extension to be provided by default with rebase

[Martin Geisler]

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.

> That said, there are certainly cases where it's good to separate the
> steps, and for that use merge. I just don't see how an automatic
> decision can be made about that :)

I see it as a conservative estimate:

* if 'hg merge' would produce an empty merge changeset, then do 'hg
  rebase' instead since no conflict resolution information is lost by
  doing that.

* if 'hg merge' would require conflicts to be solved, then record them
  as a "proper" merge changeset.

>> IMHO, I think you'd have to think a bit outside the linux hacker box
>> to appreciate rebaseif's merits. ;)
>
> Well, I'm hardly in the box... apart from working on Mercurial, I do
> closed source bussiness programming for a living :p

Heh, I read that as a 'closet ... programming' at first :)

-- 
Martin Geisler

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