Why not rebase instead of merge?

[Geoffrey Mainland]

One rebase workflow is described on the wiki:

http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Therebaseworkflow

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 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