Request for rebaseif extension to be provided by default with rebase

[Sune Foldager]

On 2011-05-23 15:54, Marcus Lindblom wrote:
>>>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.)

Think of mercurial: I update to tip and work on a feature (one changeset).
After a while, I am ready to push but someone made a slightly conflicting
change. If I merge, everyone can see that I started working on the feature
earlier than the other guys (that's ok, I suppose), and we get an extra
changeset in the tree (clutter).

But what do we gain from that? Nothing, really. My merging/rebasing would
be similar to my starting to work on the feature after the other guy, and
to the rest of the project this distinction is irrelevant and just adds
clutter.

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

But I could just as easily make manual implementation errors. After a rebase,
I always have to run the test suite anyway since stuff can and does easily
break in APIs like ours even without conflicts in the merge sense.

>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 don't see how merge is safer than rebase. You only have two changesets that
work if you merged correctly, just as you only have a changeset that works
after rebasing, if you rebased correctly.

Now, sometimes it can be easier to merge if there are a lot of conflicts,
because you can then retry and redo the merge several times without losing
anything. To do that with rebase, you'd need to backup your changesets to
a bundle, or similar, before starting.

>(i.e. I've personally stopped worrying and started to love the merge. ;)

Yeah, merge is nice until you are our company where there are like 50 branches
and 160 devs. We have to merge between branches, of course, but if we ALSO
started using it for everything else..... :p

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

Yes, it might be a good idea. Although, I'd rather make the decision of when
to use what based on stuff like "is this a large set of related changes?" and
"did I merge stuff in myself as part of development?" etc. :)

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

Right.... if I scroll back in our history using hgtk or hg glog or whatever,
it doesn't fit on my screen, horizontally :p

>So, should we call this 'rebaseif', 'fetchif' or maybe 'marcus-merge' ? ;-P

I vote for marcus-merge. This would be similar to another feature called
peter-branches ;)

>(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?

I would be fine with adding it as an option to rebase if I understood the
reasoning behind its use better :-p.

-Sune