Request for rebaseif extension to be provided by default with rebase
Na'Tosha Bard
natosha at unity3d.com
Tue May 24 12:18:06 UTC 2011
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>
More information about the Mercurial
mailing list