Re: Why not rebase instead of merge?

One rebase workflow is described on the wiki: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Therebasewor... I think the GHC history would be much easier to understand if we just got rid of empty merge commits. Doing that should be almost free, because if merging a branch results in no conflicts, i.e., an empty merge commit, then a rebase would also have resulted in no conflicts, requiring no manual fixup by the committer. Non-empty merge commits are a different issue. I have my opinions on that matter, squashing, etc., but I am only advocating that we make an effort to eliminate *empty* merge commits. It happens that I aggressively rebased my SIMD patches. I am confident that this effort made my patch set *much* easier to understand (for me and others!), but I am not trying to force that workflow on anyone. Geoff On 02/23/2013 10:33 PM, Simon Peyton-Jones wrote:

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