# Help understanding "rebase" 3 messages from 2009-03-10 to 2009-03-11. Participants: John M. Dlugosz, Brandon Casey, Michael J Gruber. Thread: https://gitlist.dev/t/18255 ## John M. Dlugosz, 2009-03-10 21:07 Subject: Help understanding "rebase" Message-ID: URL: https://gitlist.dev/e/gp6kqj%24tkb%241%40ger.gmane.org ``` Here is the situation: An old topic branch containing 3 commits. A dev branch that has recently been merged. To catch up the topic's work before adding it to dev, I expected that rebase would do what I ended up doing manually, detailed below. Instead, it crunched away for a long time and gave errors applying patches. So I did it manually by checking out dev, then cherry-picking each of the three commits. Actually, this left it on top of dev, but suppose I had created a new branch at dev, cherry-picked the stuff from the old topic branch, and then deleted the old topic branch. Now I have a new topic branch with the rebased changes, albeit with a different branch name. Point is, there were no conflicts and the changes were simple, so cherry-picking each node was clean. So, what did the rebase command try to do? I think it may have something to do with finding a common root between the topic and dev, which, due to the merge, was a long way back. Something like this: o--o-- ... --o / \ A--...--B-- ... --C--D <== dev \ q--r--s <== topic I was able to cherry-pick q,r,s on top of D without any issues. So why did rebase get in such a tizzy? --John ``` ## Brandon Casey, 2009-03-10 21:30 Subject: Re: Help understanding "rebase" Message-ID: URL: https://gitlist.dev/e/KVXTFwpJn-0uEQYfgfg9YwrrimNYx6hbxe73y6qLYxfHYZH9eE4N4g%40cipher.nrlssc.navy.mil In-Reply-To: ``` John M. Dlugosz wrote: > Here is the situation: An old topic branch containing 3 commits. A dev > branch that has recently been merged. To catch up the topic's work > before adding it to dev, I expected that rebase would do what I ended up > doing manually, detailed below. > > Instead, it crunched away for a long time and gave errors applying patches. > > So I did it manually by checking out dev, then cherry-picking each of > the three commits. Actually, this left it on top of dev, but suppose I > had created a new branch at dev, cherry-picked the stuff from the old > topic branch, and then deleted the old topic branch. Now I have a new > topic branch with the rebased changes, albeit with a different branch > name. Point is, there were no conflicts and the changes were simple, so > cherry-picking each node was clean. > > So, what did the rebase command try to do? I think it may have > something to do with finding a common root between the topic and dev, > which, due to the merge, was a long way back. Something like this: > > o--o-- ... --o > / \ > A--...--B-- ... --C--D <== dev > \ > q--r--s <== topic > > > I was able to cherry-pick q,r,s on top of D without any issues. So why > did rebase get in such a tizzy? It may help those who know the internals of git-rebase if you supplied the commands you used and your git version. So, you're saying you did git checkout topic git rebase dev or the equivalent git rebase dev topic ? Are you sure you didn't get the arguments to rebase reversed? -brandon ``` ## Michael J Gruber, 2009-03-11 09:24 Subject: Re: Help understanding "rebase" Message-ID: <49B7835F.4020503@drmicha.warpmail.net> URL: https://gitlist.dev/e/49B7835F.4020503%40drmicha.warpmail.net In-Reply-To: ``` Brandon Casey venit, vidit, dixit 10.03.2009 22:30: > John M. Dlugosz wrote: >> Here is the situation: An old topic branch containing 3 commits. A dev >> branch that has recently been merged. To catch up the topic's work >> before adding it to dev, I expected that rebase would do what I ended up >> doing manually, detailed below. >> >> Instead, it crunched away for a long time and gave errors applying patches. >> >> So I did it manually by checking out dev, then cherry-picking each of >> the three commits. Actually, this left it on top of dev, but suppose I >> had created a new branch at dev, cherry-picked the stuff from the old >> topic branch, and then deleted the old topic branch. Now I have a new >> topic branch with the rebased changes, albeit with a different branch >> name. Point is, there were no conflicts and the changes were simple, so >> cherry-picking each node was clean. >> >> So, what did the rebase command try to do? I think it may have >> something to do with finding a common root between the topic and dev, >> which, due to the merge, was a long way back. Something like this: >> >> o--o-- ... --o >> / \ >> A--...--B-- ... --C--D <== dev >> \ >> q--r--s <== topic >> >> >> I was able to cherry-pick q,r,s on top of D without any issues. So why >> did rebase get in such a tizzy? > It may help those who know the internals of git-rebase if you supplied the > commands you used and your git version. > > So, you're saying you did > > git checkout topic > git rebase dev > > or the equivalent > > git rebase dev topic > > ? Are you sure you didn't get the arguments to rebase reversed? > > -brandon > That happens very easily: You want to rewrite dev using rebase, so you check out dev. You want to rebase the topic branch, so you run "git rebase topic". Very logical, but the wrong way round... The doc is clear, though. A useful mnemonic is that git rebase A B is about the commits A..B (B defaulting to the current branch), and that the new B after rebasing will be B' = C + (A..B) where C is the value of --onto, which defaults to A. The point of rebase is that A + (A..B) does not equal B in general, even though A..B=^A B ;) git rebase A does not rewrite/rebase A! I'll think about a concise first paragraph for git-rebase.txt. Michael ```