Why not rebase instead of merge?

[Simon Peyton-Jones]

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