Why not rebase instead of merge?
simonpj at microsoft.com
Sat Feb 23 23:33:19 CET 2013
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
* fix conflicts
* revalidate if the conflicts look at all suspicious
| -----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.
| ghc-devs mailing list
| ghc-devs at haskell.org
More information about the ghc-devs