Why not rebase instead of merge?

Geoffrey Mainland

22 Feb 2013 22 Feb '13

11:50 a.m.

I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I always rebase my work instead of merge. Is there a reason this is not standard practice in the repo? It certainly makes for a nicer history. Thanks, Geoff

Show replies by date

Andy Georges

22 Feb 22 Feb

12:01 p.m.

On 22 Feb 2013, at 17:50, Geoffrey Mainland wrote:

...

I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I always rebase my work instead of merge. Is there a reason this is not standard practice in the repo? It certainly makes for a nicer history.

I guess because rebasing means actually rewriting history. Which is undesirable in itself. Once commits have been pushed out, you should never rebase, afaik. Regards, -- Andy

Stephen Paul Weber

12:05 p.m.

Somebody claiming to be Andy Georges wrote:

...

On 22 Feb 2013, at 17:50, Geoffrey Mainland wrote:

...
I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I guess because rebasing means actually rewriting history. Which is undesirable in itself. Once commits have been pushed out, you should never rebase, afaik.

git pull --rebase will only end up rebasing commits you have that aren't in the remote. So no public history changes unless you've pushed somewhere else already. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Geoffrey Mainland

12:11 p.m.

On 02/22/2013 05:05 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Andy Georges wrote:

...
On 22 Feb 2013, at 17:50, Geoffrey Mainland wrote:

...
I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable.

I guess because rebasing means actually rewriting history. Which is undesirable in itself. Once commits have been pushed out, you should never rebase, afaik.

git pull --rebase will only end up rebasing commits you have that aren't in the remote. So no public history changes unless you've pushed somewhere else already.

I am advocating rebasing before you push, so no public history is rewritten. I am most definitely not advocating rebasing previously-pushed work. My personal opinion is that all non-public branched should be rebased. However, I would be very happy just to avoid empty merge commits. Geoff

Johan Tibell

12:08 p.m.

On Fri, Feb 22, 2013 at 8:50 AM, Geoffrey Mainland wrote:

...

I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I always rebase my work instead of merge. Is there a reason this is not standard practice in the repo? It certainly makes for a nicer history.

When we switched we didn't want to affect people's current workflow too much (i.e. they already had to learn git so we kept rebasing out of it at the beginning.) -- Johan

Geoffrey Mainland

12:12 p.m.

On 02/22/2013 05:08 PM, Johan Tibell wrote:

...

On Fri, Feb 22, 2013 at 8:50 AM, Geoffrey Mainland wrote:

I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I always rebase my work instead of merge. Is there a reason this is not standard practice in the repo? It certainly makes for a nicer history.

When we switched we didn't want to affect people's current workflow too much (i.e. they already had to learn git so we kept rebasing out of it at the beginning.)

-- Johan

That's a good reason. Might it be time to revisit the question? Geoff

Bryan O'Sullivan

2:07 p.m.

On Fri, Feb 22, 2013 at 9:12 AM, Geoffrey Mainland wrote:

...

That's a good reason. Might it be time to revisit the question?

Surely this isn't important at all?

Austin Seipp

2:54 p.m.

Yes, it is - and I think there's already evidence of this being the case. The history of GHC HQ & Co. submitting 'mega patches' to the master branch - for implementing 'complete' functionality of something - *after* working out the details on a branch is not uncommon. A lot of features have been integrated this way in some form. This his how the new backend was merged, the 7.0.x typechecker overhaul, the 7.4.x typechecker overhaul, type holes by Thijs/Sean, new typeable by Jose, and countless other mid to large size things have landed this way over the past few years. 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. These 'mega patch' merge strategies are - at heart - nothing more than a rebase already, and there have been plenty of discussions in the past about this 'mega patch' approach vs merging long standing branches. This discussion goes back even before we were using Git and were still on Darcs. I don't think it's necessarily the most important discussion, but it is certainly something more than "not important at all." (I support this, FWIW. I also rebase all incoming patches on top of master before I commit, and I think this leads to a far more legible and easy to follow history for other developers, and myself down the line.) On Fri, Feb 22, 2013 at 1:07 PM, Bryan O'Sullivan wrote:

...

On Fri, Feb 22, 2013 at 9:12 AM, Geoffrey Mainland wrote:

...
That's a good reason. Might it be time to revisit the question?

Surely this isn't important at all? _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin

Johan Tibell

2:58 p.m.

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.

Austin Seipp

3 p.m.

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

Simon Peyton-Jones

23 Feb 23 Feb

5:33 p.m.

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 | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Johan Tibell

10:15 p.m.

On Sat, Feb 23, 2013 at 2: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

It ought to be the same, with pull replaced with pull --rebase. That being said it's late here and I haven't thought it over carefully. I suggest you try it on a small change first. :)

Alexander Kjeldaas

24 Feb 24 Feb

5:43 a.m.

You'd optionally want to squ On Sun, Feb 24, 2013 at 4:15 AM, Johan Tibell wrote:

...

On Sat, Feb 23, 2013 at 2: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

...

Here you might want to do a git rebase -i <when-you-split-from-main-branch> and squash unnecessary commits into larger ones.

...

* pull

...

And then git pull --rebase Since rebase will generate conflicts on each commit, it's better to squash unnecessary stuff before this pull, I think.

...

* fix conflicts

...
* revalidate if the conflicts look at all suspicious * push

It ought to be the same, with pull replaced with pull --rebase. That being said it's late here and I haven't thought it over carefully. I suggest you try it on a small change first. :)

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Andy Adams-Moran

2:05 p.m.

Can the standard workflow be scripted? On Sun, Feb 24, 2013 at 2:43 AM, Alexander Kjeldaas wrote:

...

You'd optionally want to squ

On Sun, Feb 24, 2013 at 4:15 AM, Johan Tibell wrote:

...
On Sat, Feb 23, 2013 at 2: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

Here you might want to do a git rebase -i <when-you-split-from-main-branch> and squash unnecessary commits into larger ones.

...
...
* pull

And then git pull --rebase

Since rebase will generate conflicts on each commit, it's better to squash unnecessary stuff before this pull, I think.

...
...
* fix conflicts * revalidate if the conflicts look at all suspicious * push

It ought to be the same, with pull replaced with pull --rebase. That being said it's late here and I haven't thought it over carefully. I suggest you try it on a small change first. :)

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Stephen Paul Weber

5:50 p.m.

Somebody claiming to be Alexander Kjeldaas wrote:

...

Here you might want to do a git rebase -i <when-you-split-from-main-branch> and squash unnecessary commits into larger ones.

I've never understood why people do this. It seems to violate the purpose of making good atomic commits in the first place. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Johan Tibell

6:52 p.m.

On Sun, Feb 24, 2013 at 2:50 PM, Stephen Paul Weber < singpolyma@singpolyma.net> wrote:

...

Somebody claiming to be Alexander Kjeldaas wrote:

...
Here you might want to do a git rebase -i and squash unnecessary commits into larger ones.

I've never understood why people do this. It seems to violate the purpose of making good atomic commits in the first place.

Ideally people should always make nice commits as they work on code. In practice that rarely happens. For example, sometimes when you work on some change you might see some unrelated problem and fix it then and there, so you don't forget. Rebasing allows you to fix that up later.

David Terei

7:50 p.m.

doing this allows me when working to make commits more arbitrarily, such that it suits my development flow. (e.g., a commit simply because I'm changing from workstation to laptop). Fixing up after the work is done can result in much nicer, more atomic commits. i.e., hindsight and all that. On 24 February 2013 14:50, Stephen Paul Weber wrote:

...

Somebody claiming to be Alexander Kjeldaas wrote:

...
Here you might want to do a git rebase -i <when-you-split-from-main-branch> and squash unnecessary commits into larger ones.

I've never understood why people do this. It seems to violate the purpose of making good atomic commits in the first place.

-- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Stephen Paul Weber

25 Feb 25 Feb

10:13 a.m.

Somebody claiming to be David Terei wrote:

...

doing this allows me when working to make commits more arbitrarily, such that it suits my development flow. (e.g., a commit simply because I'm changing from workstation to laptop). Fixing up after the work is done can result in much nicer, more atomic commits. i.e., hindsight and all that.

Ah, this makes sense. In the past I've seen people `rebase -i` to squash an entire feature branch into a single commit, and similar, which is less atomic. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Geoffrey Mainland

3:29 a.m.

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

Ian Lynagh

22 Feb 22 Feb

12:09 p.m.

On Fri, Feb 22, 2013 at 04:50:13PM +0000, Geoffrey Mainland wrote:

...

I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I always rebase my work instead of merge. Is there a reason this is not standard practice in the repo? It certainly makes for a nicer history.

I generally rebase when I'm sure my local patches are only in one repo, but when I've been push/pulling between different machines I don't think it's worth the hassle. Thanks Ian

4468

Age (days ago)

4471

Last active (days ago)

List overview

Download

19 comments

11 participants

participants (11)

Alexander Kjeldaas
Andy Adams-Moran
Andy Georges
Austin Seipp
Bryan O'Sullivan
David Terei
Geoffrey Mainland
Ian Lynagh
Johan Tibell
Simon Peyton-Jones
Stephen Paul Weber