Why not rebase instead of merge?

Austin Seipp aseipp at pobox.com
Fri Feb 22 20:54:41 CET 2013


Yes, it is - and I think there's already evidence of this being the case.

The history of GHC HQ & Co. submitting 'mega patches' to the master
branch - for implementing 'complete' functionality of something -
*after* working out the details on a branch is not uncommon. A lot of
features have been integrated this way in some form. This his how the
new backend was merged, the 7.0.x typechecker overhaul, the 7.4.x
typechecker overhaul, type holes by Thijs/Sean, new typeable by Jose,
and countless other mid to large size things have landed this way over
the past few years.

In fact, the only major feature overhaul/addition I can think of
recently that was *not* consolidated into a mega patch near the end of
development was the new I/O manager that hit base. That was actually
branch-merged.

These 'mega patch' merge strategies are - at heart - nothing more than
a rebase already, and there have been plenty of discussions in the
past about this 'mega patch' approach vs merging long standing
branches. This discussion goes back even before we were using Git and
were still on Darcs. I don't think it's necessarily the most important
discussion, but it is certainly something more than "not important at
all."

(I support this, FWIW. I also rebase all incoming patches on top of
master before I commit, and I think this leads to a far more legible
and easy to follow history for other developers, and myself down the
line.)

On Fri, Feb 22, 2013 at 1:07 PM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> On Fri, Feb 22, 2013 at 9:12 AM, Geoffrey Mainland <mainland at apeiron.net>
> wrote:
>>
>> That's a good reason. Might it be time to revisit the question?
>
>
> Surely this isn't important at all?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,
Austin



More information about the ghc-devs mailing list