Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m trying to figure out why rebase requires a three-way merge. For instance, if we have
A1 - A2
\
B1
And I’ve checked out B1, and I want to perform:
git rebase A2
why does git merge A2, B1 AND A1? Why wouldn’t A2 and B1 suffice? I mean, don’t A2 and B1 as commit contain the complete current snapshot of the tree?
To perform a merge, Git needs to find out, what exactly happened in the two branches since the common ancestor (
A1). As you have said correctly, Git stores snapshots of the commits/trees so to get an actual change set, it has to compareA2toA1andB1toA1and then merge those individual change sets.The same thing happens in a rebase. To apply the change set of
A2onB1, we first need to calculate that change set from the differences betweenA1andA2. And then we can apply that toB1. You can think of a rebase as something similar to an automated generation of patch files. First it generates all those patch files from the old branch and applies them then to the current HEAD.So, we need all those three commits to actually calculate the differences, as we cannot figure out what happened in a commit just by looking at that commit.