Request for rebaseif extension to be provided by default with rebase

[Na'Tosha Bard]

On Tue, May 24, 2011 at 2:20 PM, Sune Foldager <cryo at cyanite.org> wrote:

> On 2011-05-24 14:18, Na'Tosha Bard wrote:
>
>> On Tue, May 24, 2011 at 1:31 PM, Martin Geisler <mg at aragost.com> wrote:
>>
>>> 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.
>>
>
> Would be great, and it's an instance of a general wish to be able to 'zoom
> in' on changesets to see more internal development details. I'd really like
> a feature like that. With the current model, though, it's not possible, and
> you have to use merge to keep those details.


I don't think we'd like to see merge to disappear, just add some additional
functionality. Would it be possible to somehow "add on" to merge to keep
some more information around to be able to show these "interesting details"
then add some sort of "show merge details on revision X" feature that can
display it?

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/0025cb31/attachment.html>