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: [email protected] [mailto:[email protected]] On | Behalf Of Austin Seipp | Sent: 22 February 2013 20:00 | To: Johan Tibell | Cc: Geoffrey Mainland; [email protected] | 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 <[email protected]> wrote: | > On Fri, Feb 22, 2013 at 11:54 AM, Austin Seipp <[email protected]> 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 | [email protected] | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
