I already explained this a while ago on a pull request at https://github.com/sympy/sympy/pull/1065#issuecomment-4677173, so I'll just take my response from there:
""" The difference [between rebasing and merging] is what it does to the commits. It's easier to visualize with something like gitk. Rebase takes all the commits and reapplies them one at a time on top of master, so that you have a linear history. Merging creates a special commit, called a merge commit, that linkes the two branches. To understand the difference, you should understand how commits work. A commit is just a changeset that is applied on top of other changesets. Each commit is hashed using the SHA1 algorithm. The hash includes the changes of the commit, the commit message, some metadata like the date and author, and the SHA1 hash(s) of the commit(s) it was applied on top of. Because the hash includes the previous commit's hash in it, a commit actually contains information about its entire history. Now, because rebase takes commits and reapplies them, this effectively creates new commits. The SHA1 has will change, and as far as git is concerned, they are different. That's why when you rebased, it moved the commits later in pull request discussion. For example, 3b0ea2b is now c19cce1. When you merge, on the other hand, the commits are not changed at all. Every commit remains exactly the same. Rather, a new commit is made that links the two branches together. The advantage of merging is that if someone else has work based off of your history, it will not affect them. If you rebase, since it changes the history, it will mess things up, and you can end up with duplicate commits in the history. Another advantage to merging is that you can see what the merge conflicts were and how they were resolved, because that information will be in the merge commit. If you rebase, you lose this information, because only the new commits will remain. The advantage of rebasing is that you can go ahead and modify other aspects of the history as well, such as editing commit messages, squashing or splitting commits, deleting commits, injecting new commits, or any other way you can think of. All of these would change the commits's SHA1, so they will create new commits. Rebasing also creates a nice linear history, which looks nicer in gitk (but there's really no other reason why this is desirable). Since no one else was using your code, merging or rebasing didn't matter. If in the future you are working on a large branch, and other people may be working off of it, you should always merge, or else it will mess them up. Is that all clear? """ The issue becomes very important if other people are basing their work off of yours. You might find https://groups.google.com/d/topic/sympy/BTleGiUeUJI/discussion and the corresponding blog post to be an interesting read. Basically, Mateusz had a large branch with his work in the polys, which he occasionally rebased over master. I based my Risch work off of his, but only merged. The result is that my integration3 branch has many duplicate commits in its history. The other result was that many of my merges were very painful (this was not the only reason for this, but it played a big part). Aaron Meurer On Wed, Apr 4, 2012 at 4:16 PM, [email protected] <[email protected]> wrote: >> Yeah, this is where the merging instead of rebasing thing strategy >> comes in handy. You just do all your changes in branches, and merge >> them together when you need them. Since the merge doesn't affect the >> original commit, this won't create duplicate commits, and will extend >> naturally when the commit is merged into master. >> > > When you have the time could you explain (or point to an explanation) > about the merge vs rebase strategy. It is not clear to me how this > works. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
