Request for rebaseif extension to be provided by default with rebase

[Adrian Buehlmann]

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.

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.

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