Request for rebaseif extension to be provided by default with rebase

[Sébastien Deleuze]

Thanks for your feedback.

Pushing new heads is disabled by default (default behaviour since
Mercurial 1.5 or 1.6, don't remeber), this behaviour is enough for us.

About merge versus rebase, I think there is a big difference between
the 2 : rebase manipulates history, merge does not.
This is a big difference when conflicts are tricky, and that's why I
think rebase when there is no unresolved conflicts is better.

On Mon, May 23, 2011 at 12:43 PM, Sune Foldager <cryo at cyanite.org> wrote:
> 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
>