Request for rebaseif extension to be provided by default with rebase

[Marcus Lindblom]

Adrian Buehlmann skrev 2011-05-23 16:09:
> On 2011-05-22 20:30, Sébastien Deleuze wrote:
>> Hi,
>>
>> In my company, we are using Mercurial with more and more people, and
>> while we setup training and guidelines, I would like to share some
>> feedbacks about one point that make Mercurial a magnitude of order
>> easier to use : rebaseif extension
>> (http://mercurial.selenic.com/wiki/RebaseIfExtension).
>>
>> We are using continuous integration on 1 or 2 branches of our
>> projects, some people are usually working on the same branch. We don't
>> encourage peolple to push anonymous heads because it does not work
>> well with continous integration, and people (especially beginners) can
>> be quickly lost.
>>
>> Before discovering rebasif extension, we had some real issues to give
>> people guidelines about the right thing to do after pulling remote
>> changes. 80% of times, remote and local changes does not concern same
>> files, so rebase is fine, but in 20% of time, when there is some
>> conflict rebase can quickly become a nightmare.
>>
>> Since we have deployed rebaseif and updated our guidelines to tell
>> people to do a "pull --rebaseif" when their push failed, we have seen
>> a really strong improvement of Mercurial ease of use, people are happy
>> and efficiency is better.
>>
>> When it is possible without conflicts, a rebase is done.
>> When this is not possible, a merge occur with kdiff3 configured by default.
>> Projects history are now far better (no more bullshit merge).
>
> I think that starting e.g. kdiff3 on a conflict during 'hg pull --rebase' is
> indeed daunting for users.
>
> Using Mercurial as is, I think specifying --config ui.merge=internal:fail might
> be slightly better than just plain 'hg pull --rebase', but still not exactly what
> you proposed (example):
>
>    $ hg pull --rebase --config ui.merge=internal:fail
>    real URL is https://bitbucket.org/mirror/mercurial-crew
>    pulling from http://bitbucket.org/mirror/mercurial-crew
>    searching for changes
>    adding changesets
>    adding manifests
>    adding file changes
>    added 72 changesets with 123 changes to 50 files (+1 heads)
>    abort: unresolved conflicts (see hg resolve, then hg rebase --continue)
>
> So this example pull --rebase left unresolved conflicts and a dangling rebase.
> Yikes.
>
> Perhaps it would be nice if 'hg pull --rebase' by default would start the
> rebase part only if no conflicts (conflicts in the sense of internal:fail [1])
> are found and print a warning about the rebase not being done.
>
> In other words: 'hg pull --rebase' should only really do a rebase if the
> rebase would only be touching files that have not been modified by the
> pulled changes.
>
> But I haven't looked into how hard it would be to implement this.

If you look at rebaseif.py[2], you see it's pretty easy. Shifting to 
internal:fail instead of internal:merge is no problem at all, and 
probably a good thing too. (I didn't know about internal:fail when I 
wrote the extension.)

[2] https://bitbucket.org/marcusl/ml-hgext/src/tip/rebaseif.py

> FWIW, I would never use 'hg pull --rebase' myself. I prefer to do a plain pull,
> and then look at what I got. And then I decide what to do next myself.

You can also run rebaseif (or 'hg rebase --safeish') manually if you're 
unsure.

> [1] http://www.selenic.com/mercurial/hg.1.html#merge-tools

/Marcus