Request for rebaseif extension to be provided by default with rebase

[Marcus Lindblom]

Sune Foldager skrev 2011-05-23 15:19:
> On 2011-05-23 14:04, Sébastien Deleuze wrote:
>> 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.
>
> Yes, this is also how we prevent it, actually, since we have a wrapper
> tool most people use where there is no --force option :-p.
>
>> About merge versus rebase, I think there is a big difference between
>> the 2 : rebase manipulates history, merge does not.
>
> rebase manipulates local, unpublished, history in this case, and if you
> have philosophical objections against this (which is fair), I don't see
> how they don't apply equally to the case where there happen to be no file
> conflicts. Even with no conflicts, the merge that is implicitly done when
> you rebase, can break! This is an important point, and rebase and merge
> are equals in that respect.

Except that a rebase leaves no history over how a conflicted merge was 
resolved. (If you make an error in resolving the conflict, it's hard to 
separate the new code change from the merge work once the rebase op is 
completed and the commit is pushed.)

This is the reason why I implemented the rebaseif extension. To protect 
against (and keep history of) human manual merge errors.

Of course, changes in separate files are not always safe to reorder 
either, which is why merge is the safest default, since you have two 
commits which both work (i.e. tests pass and all that) and you can see 
how they were merge and test if the merged version is correct too.
(i.e. I've personally stopped worrying and started to love the merge. ;)

But rebaseif is a good middle-ground between rebase and merge that many 
people seem to appreciate, esp. those coming to DVCS from SVN et.al.
(Also, we're not that many devs in my current project. I understand it 
becomes more important to have a clear history once team size goes up.)

...

So, should we call this 'rebaseif', 'fetchif' or maybe 'marcus-merge' ? ;-P
(Don't get me started on 'fetch' btw. Should've been 'pull-merge'..)

I'd dislike calling it 'saferebase' because fundamentally it is not, 
IMO. 'non-conflict-rebase' is correct, but a bit wordy.

Anyway, I can merge rebaseif into rebase and add a small config that 
says "rebase_iff_no_conflicts", that enables --rebaseif behaviour. 
That'd probably be good enough and should integrate well with most GUI 
clients that support rebase on pull.

Opinions?

mvh
/Marcus