Request for rebaseif extension to be provided by default with rebase

[Na'Tosha Bard]

On Tue, May 24, 2011 at 1:31 PM, Martin Geisler <mg at aragost.com> wrote:

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

This is useful information.  I would like to see it kept around as well.


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

Yes, this has been a really big issue for us and our desired workflow.  It
would be really useful if there were some way to identify after the fact (in
a way that code review tools can be modified to use) the "interesting"
information from a merge changeset -- e.g, the result of conflict
resolutions -- and filter out the rest because it is just "noise".  Showing
this somehow after-the-fact for a rebase as well, would be ideal.

Cheers,
Na'Tosha

-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110524/68d14971/attachment.html>