Comments on: Rebase v Merge in Git http://gitguru.com/2009/02/03/rebase-v-merge-in-git/ meditations on scm using git Sat, 06 Mar 2010 13:29:39 +0000 http://wordpress.org/?v=2.8.5 hourly 1 By: Shoo http://gitguru.com/2009/02/03/rebase-v-merge-in-git/comment-page-1/#comment-43 Shoo Mon, 15 Feb 2010 13:05:54 +0000 http://gitguru.com/?p=22#comment-43 And if I may add another difference: rebase will refuse (by default) to work if you have modified files in your worktree, thus attempting to goad you into having a clean up-to-date worktree (or at least stashing the local changes) before you pull the other mods. This is usually a good idea. (This only regards files that would be touched by the commits you're about to pull. It doesn't care about modified files that have nothing to do with those mods.) And if I may add another difference: rebase will refuse (by default) to work if you have modified files in your worktree, thus attempting to goad you into having a clean up-to-date worktree (or at least stashing the local changes) before you pull the other mods. This is usually a good idea.

(This only regards files that would be touched by the commits you’re about to pull. It doesn’t care about modified files that have nothing to do with those mods.)

]]> By: Harjit http://gitguru.com/2009/02/03/rebase-v-merge-in-git/comment-page-1/#comment-34 Harjit Thu, 20 Aug 2009 21:47:06 +0000 http://gitguru.com/?p=22#comment-34 What rebase really says is, to consider the changes that are about to made to the branch, FIRST get the changes that others have already COMMITED to the branch, and then re-apply changes on top of that, irrespective of when the changes were made. This allows you to get what others before you have already commited, and shows you where your changes cause merge conflicts. Also it makes the merge upwards more meaningful, since you would normally resolve conflicts caused by your changes to previously commited changes, before merging and pushing. What rebase really says is, to consider the changes that are about to made to the branch, FIRST get the changes that others have already COMMITED to the branch, and then re-apply changes on top of that, irrespective of when the changes were made. This allows you to get what others before you have already commited, and shows you where your changes cause merge conflicts. Also it makes the merge upwards more meaningful, since you would normally resolve conflicts caused by your changes to previously commited changes, before merging and pushing.

]]> By: Marc http://gitguru.com/2009/02/03/rebase-v-merge-in-git/comment-page-1/#comment-33 Marc Thu, 02 Jul 2009 18:26:09 +0000 http://gitguru.com/?p=22#comment-33 Does rebase make the comparison between the two branches faster? Does rebase make the comparison between the two branches faster?

]]> By: long http://gitguru.com/2009/02/03/rebase-v-merge-in-git/comment-page-1/#comment-4 long Thu, 05 Feb 2009 02:49:24 +0000 http://gitguru.com/?p=22#comment-4 I've taken some liberties with the notation. A is the set of commits (a1, a2, a3...) on branch A. B is the set of commits (b1, b2, b3...) on branch B that were added after this branch was created based on branch A. A' is the set of new commits (a'1, a'2...) on branch A that need to be added to branch B via a merge or rebase. So before the merge or rebase, the current configuration of the branches are Branch A: A + A' (original set of commits and new set of commits) = a1 + a2 + a3 + ... + a'1 + a'2 +.... Branch B: A + B (original set of commits from branch A and set of commits on branch B) = a1 + a2 + a3 + ... + b1 + b2 + b3 + ... When I talk about the merge from branch A onto branch B, the addition of the sets of commits is A + B + A' = a1 + a2 + a3 + ... + b1 + b2 + b3 + ... + a'1 + a'2 + ... The order is important: You start with the original commits on branch A. The commits on branch B are added on top of those commits. And finally the new commits from branch A are added on top of those. You can also view "A + B" as the code that you see in the directory that is the end result of the set of commits A and B. Which is why I have the first statement: A + B + A' = A + A' + B Whether you choose a rebase or a merge, the final code that you see should be the same. However, the order of individual commits that go into are different. I’ve taken some liberties with the notation.

A is the set of commits (a1, a2, a3…) on branch A.
B is the set of commits (b1, b2, b3…) on branch B that were added after this branch was created based on branch A.

A’ is the set of new commits (a’1, a’2…) on branch A that need to be added to branch B via a merge or rebase.

So before the merge or rebase, the current configuration of the branches are

Branch A: A + A’ (original set of commits and new set of commits) = a1 + a2 + a3 + … + a’1 + a’2 +….
Branch B: A + B (original set of commits from branch A and set of commits on branch B) = a1 + a2 + a3 + … + b1 + b2 + b3 + …

When I talk about the merge from branch A onto branch B, the addition of the sets of commits is

A + B + A’ = a1 + a2 + a3 + … + b1 + b2 + b3 + … + a’1 + a’2 + …

The order is important: You start with the original commits on branch A. The commits on branch B are added on top of those commits. And finally the new commits from branch A are added on top of those.

You can also view “A + B” as the code that you see in the directory that is the end result of the set of commits A and B. Which is why I have the first statement:

A + B + A’ = A + A’ + B

Whether you choose a rebase or a merge, the final code that you see should be the same. However, the order of individual commits that go into are different.

]]> By: Joseph http://gitguru.com/2009/02/03/rebase-v-merge-in-git/comment-page-1/#comment-3 Joseph Wed, 04 Feb 2009 06:29:34 +0000 http://gitguru.com/?p=22#comment-3 I really would like to understand this, but I don't understand the notation. I really would like to understand this, but I don’t understand the notation.

]]>