Request for rebaseif extension to be provided by default with rebase

[Sune Foldager]

On 2011-05-22 20:30, Sébastien Deleuze wrote:

Where I work, we use Mercurial for 160 or so developers. Our policy is
somewhat similar:

>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.

We strongly forbid people to push multiple heads. This is prevented with
hooks.

>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.

Exeactly the same way as merge can become a nightmare, though? They use
the same machinery.

>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).

We forbid people from pushing multiple heads, and they are then free to
rebase or merge their own changes as they see fit. Generally, people use
rebase. I don't understand why it would automatically be better to use a
merge if there is a conflict, since rebase and merge invoke the exact same
merge machinery (more or less on the same changesets as well).

The most common case is rebasing single commits, and I then we can pick
between these two:

rebase: the feature ends up as a single commit, like before.

merge: the feature ends up as a single commit plus a merge detailing how
it was changed to cope with changes upstream since its development.

I don't see how those details (for merge) are important to anyone else;
they are contingent on when the feature was developed, and how long it took.
This doesn't need to be preserved in history. Of course the rebaser is
expected to inspect the changes he makes; after all, he or she resolves the
conflicts themselves.

Of course if you have 20 changesets or if you merged other branches in
or stuff like that, a merge can become desirable (or even the only way).

>I am strongly convinced rebaseif is a killer feature for Mercurial,
>more than 40 developpers (beginners to experts) are now using it, they
>all claims that ths feature make their job easier.

I am more convinced that rebase is a killer feature for those settings,
as explained above, and not rebaseif, but.. YMMV :)

-Sune