RE: Why not rebase instead of merge?

I'm ok with changing my workflow if that'd give better history. But someone would need to explain the new workflow carefully on the wiki. At the moment my general plan is: * make some changes * commit as patches * validate * pull * fix conflicts * revalidate if the conflicts look at all suspicious * push Simon | -----Original Message----- | From: ghc-devs-bounces@haskell.org [mailto:ghc-devs-bounces@haskell.org] On | Behalf Of Austin Seipp | Sent: 22 February 2013 20:00 | To: Johan Tibell | Cc: Geoffrey Mainland; ghc-devs@haskell.org | Subject: Re: Why not rebase instead of merge? | | Ah yes, I can see this more clearly now looking at the history. Thanks | for correcting me. | | On Fri, Feb 22, 2013 at 1:58 PM, Johan Tibell wrote: | > On Fri, Feb 22, 2013 at 11:54 AM, Austin Seipp wrote: | >> | >> 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. | > | > | > I merged that and I followed the typical git practice of rebasing but | > committing with --no-ff to create a single merge commit so that it's easier | > to find the whole feature in the history. | > | | | | -- | Regards, | Austin | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs