Request for rebaseif extension to be provided by default with rebase

[Adrian Buehlmann]

On 2011-05-24 10:49, Marcus Lindblom wrote:
> 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.)

Yea. I was pondering about outright changing 'hg pull --rebase' to (roughly)
something like:

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -570,6 +570,7 @@
             commands.postincoming = origpostincoming
         revspostpull = len(repo)
         if revspostpull > revsprepull:
+            opts['tool'] = "internal:fail"
             rebase(ui, repo, **opts)
             branch = repo[None].branch()
             dest = repo[branch].rev()

on mercurial's own rebase.

Which would at least go like this (example):

  $ hg pull --rebase
  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)

hard-coded.

The user could continue with checking what was causing the conflict (example
continued):

  $ hg resolve -l
  U mercurial/revlog.py

  $ hg -q parents
  14393:bb5cbc16349e
  14321:b7a77cf76ec7

So, at this point, we do already have an uncommitted merge, but with unresolved
conflicts.

Assuming the user then manually resolves the conflict by editing the files in
question, he can then mark them as resolved, ignore the interrupted rebase and
just commit it as a full-blown merge.

Example continued:

  $ hg resolve -m mercurial/revlog.py

  $ hg resolve -l
  R mercurial/revlog.py

  $ hg commit -m "merged"

  $ hg log -r .
  changeset:   14394:0779dc213ec6
  tag:         tip
  parent:      14393:bb5cbc16349e
  parent:      14321:b7a77cf76ec7
  user:        Adrian Buehlmann <adrian at cadifra.com>
  date:        Tue May 24 11:51:40 2011 +0200
  summary:     merged

Or, alternatively, he probably can continue the rebase if he still prefers
to rebase.