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 <[email protected]> wrote: > On Fri, Feb 22, 2013 at 9:12 AM, Geoffrey Mainland <[email protected]> > 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 > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
