Comments on: Merge vs. Rebase – A deep dive into the mysteries of revision control

By: Geoffrey

Geoffrey — Fri, 27 Jan 2012 13:31:16 +0000

Aleksandar, I’ve just read that article you linked, and I can tell you it’s an actually worse explanation.

David’s schemas are right, when you rebase a branch (for example “feature”) on another (let’s say “master”), all commits from “feature” not reachable from “master” are applied to “master”. Nothing ever gets “uncommited” or whatever nonsense.

You can actually DIY rebase your branch by cherry-pick’ing every commit from “feature” not on “master” to “master” the reset –hard your “feature” branch to the last cherry-pick you did, the end result will be exactly the same than a rebase.

I suggest you read http://think-like-a-git.net/sections/rebase-from-the-ground-up.html to get a good understanding of how rebase works.

By: Geoffrey

Geoffrey — Fri, 27 Jan 2012 13:16:04 +0000

“Git literally take this commits as patches by removing the commits from the history, creating patches out of it and applythem on top of the new branch”

The “removing the commits from the history” part is false, they actually are still in git’s commits graph, but they are now “HEADless” (which means, they cannot be reached from any existing branch and will be collected by git gc at some point). Which means you could very well reset –hard 322ac (I took the commit id from your example) and plain cancel your rebase.

About conflict resolution, git has a command to REcord conflict REsolution and REplay it, it’s called rerere. Could prove handy if you have to solve the same conflict over and over again.

By: Aleksandar Kostadinov

Aleksandar Kostadinov — Sat, 10 Sep 2011 19:50:09 +0000

Excuse me, I’ve pasted feel link above and I cannot edit the comment. Here’s the correct one: http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

By: Aleksandar Kostadinov

Aleksandar Kostadinov — Sat, 10 Sep 2011 19:48:17 +0000

Excuse me but these pictures and explanations do not look correct to me (or maybe the way it is explained can only confuse). I am learning git today for the first time but another article [1] makes much more sense to me.

[1] http://jarrodspillers.disqus.com/git_merge_vs_git_rebase_avoiding_rebase_hell_jarrod_spillers/latest.rss

By: FallenGameR

FallenGameR — Tue, 06 Sep 2011 20:27:33 +0000

Enjoyed the post ;)

By: dsp

dsp — Sat, 28 May 2011 13:01:08 +0000

Maybe it’s not written correctly, but there are two situations where rebasing can cause more conflicts:
1) If you try to merge a rebased branch with a branch that contains the non rebased changets. In that case you have commits that introduce the same change which will cause a lot of conflicts
2) During rebasing itself. When you rebase a branch and a conflict appears. As far as I know, during a rebase you loose the information of the common ancestor, resulting in a similar merge like SVN would do as it just applies the changes on top of the current working directory, not making use of the common ancestor to resolve parts of the conflict. In that case you might end up with more conflicts.

Otherwise you are absolutly right. Once a you rebased successfully and then merge with a branch, it usually becomes easier and you will have less conflicts as your common ancestor is more recent and thefore you have less changests that can introduce the conflict.

By: david

david — Fri, 27 May 2011 19:37:41 +0000

Don’t understand what you mean in your deep dive explanation when you say rebasing will produce more conflicts. You make it sound like conflict resolution becomes harder, but surely it gets easier, as you are splitting your conflicts across multiple commits rather than having to handle them in one changeset merge.

By: Basil

Basil — Sat, 12 Mar 2011 05:59:34 +0000

Thanks for the article, really helpful.

I think now that I’ll never use rebase.

As far as I see, the only disadvantage of using merge is that there will exist some extra changesets in the repository (corresponding to the stable branch). Is that really a problem?
Are there any other advantages of using rebase which I overlooked?

By: Bjarne Christiansen

Bjarne Christiansen — Sat, 07 Mar 2009 12:38:56 +0000

> Thanks for sharing – keep up the work!
That should of cause have been:
“Thanks for sharing – keep up the _good_ work!” ;-)

By: Bjarne Christiansen

Bjarne Christiansen — Sat, 07 Mar 2009 12:21:04 +0000

> Disclaimer: I never read this article myself
You should, it’s really good! ;-)

Seriously, it’s the best article I have read on rebase so far. Good and important point about the duplicated commits, definitely worth sharing!

It reminded me about the movie “Back to the Future”, you really need to be careful when re-writing history :o) In Mercurial re-writing history can’t be done, unless you enable some ext., there is a good reason for that…

Thanks for sharing – keep up the work!