{"thread":{"id":"18255","subject":"Help understanding \"rebase\"","startedAt":"2009-03-10T21:07:27Z","lastAt":"2009-03-11T09:24:47Z","messageCount":3,"participants":["John M. Dlugosz","Brandon Casey","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"107610","messageId":"gp6kqj$tkb$1@ger.gmane.org","threadId":"18255","inReplyTo":null,"subject":"Help understanding \"rebase\"","fromName":"John M. Dlugosz","fromEmail":"ngnr63q02@sneakemail.com","sentAt":"2009-03-10T21:07:27Z","receivedAt":"2009-03-10T21:07:27Z","isPatch":false,"sender":{"key":"ngnr63q02@sneakemail.com","avatar":null},"body":"Here is the situation:  An old topic branch containing 3 commits.  A dev branch that has \nrecently been merged.  To catch up the topic's work before adding it to dev, I expected \nthat rebase would do what I ended up doing manually, detailed below.\n\nInstead, it crunched away for a long time and gave errors applying patches.\n\nSo I did it manually by checking out dev, then cherry-picking each of the three commits. \nActually, this left it on top of dev, but suppose I had created a new branch at dev, \ncherry-picked the stuff from the old topic branch, and then deleted the old topic branch. \n  Now I have a new topic branch with the rebased changes, albeit with a different branch \nname.  Point is, there were no conflicts and the changes were simple, so cherry-picking \neach node was clean.\n\nSo, what did the rebase command try to do?  I think it may have something to do with \nfinding a common root between the topic and dev, which, due to the merge, was a long way \nback.  Something like this:\n\n\t  o--o--   ...  --o\n\t /                 \\\n\tA--...--B--   ... --C--D <== dev\n\t         \\\n                   q--r--s  <== topic\n\n\nI was able to cherry-pick q,r,s on top of D without any issues.  So why did rebase get in \nsuch a tizzy?\n\n--John\n"},{"id":"107611","messageId":"KVXTFwpJn-0uEQYfgfg9YwrrimNYx6hbxe73y6qLYxfHYZH9eE4N4g@cipher.nrlssc.navy.mil","threadId":"18255","inReplyTo":"gp6kqj$tkb$1@ger.gmane.org","subject":"Re: Help understanding \"rebase\"","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2009-03-10T21:30:21Z","receivedAt":"2009-03-10T21:30:21Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"\nJohn M. Dlugosz wrote:\n> Here is the situation:  An old topic branch containing 3 commits.  A dev\n> branch that has recently been merged.  To catch up the topic's work\n> before adding it to dev, I expected that rebase would do what I ended up\n> doing manually, detailed below.\n> \n> Instead, it crunched away for a long time and gave errors applying patches.\n> \n> So I did it manually by checking out dev, then cherry-picking each of\n> the three commits. Actually, this left it on top of dev, but suppose I\n> had created a new branch at dev, cherry-picked the stuff from the old\n> topic branch, and then deleted the old topic branch.  Now I have a new\n> topic branch with the rebased changes, albeit with a different branch\n> name.  Point is, there were no conflicts and the changes were simple, so\n> cherry-picking each node was clean.\n> \n> So, what did the rebase command try to do?  I think it may have\n> something to do with finding a common root between the topic and dev,\n> which, due to the merge, was a long way back.  Something like this:\n> \n>       o--o--   ...  --o\n>      /                 \\\n>     A--...--B--   ... --C--D <== dev\n>              \\\n>                   q--r--s  <== topic\n> \n> \n> I was able to cherry-pick q,r,s on top of D without any issues.  So why\n> did rebase get in such a tizzy?\n\nIt may help those who know the internals of git-rebase if you supplied the\ncommands you used and your git version.\n\nSo, you're saying you did\n\n   git checkout topic\n   git rebase dev\n\nor the equivalent\n\n   git rebase dev topic\n\n?  Are you sure you didn't get the arguments to rebase reversed?\n\n-brandon\n"},{"id":"107658","messageId":"49B7835F.4020503@drmicha.warpmail.net","threadId":"18255","inReplyTo":"KVXTFwpJn-0uEQYfgfg9YwrrimNYx6hbxe73y6qLYxfHYZH9eE4N4g@cipher.nrlssc.navy.mil","subject":"Re: Help understanding \"rebase\"","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-11T09:24:47Z","receivedAt":"2009-03-11T09:24:47Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Brandon Casey venit, vidit, dixit 10.03.2009 22:30:\n> John M. Dlugosz wrote:\n>> Here is the situation:  An old topic branch containing 3 commits.  A dev\n>> branch that has recently been merged.  To catch up the topic's work\n>> before adding it to dev, I expected that rebase would do what I ended up\n>> doing manually, detailed below.\n>>\n>> Instead, it crunched away for a long time and gave errors applying patches.\n>>\n>> So I did it manually by checking out dev, then cherry-picking each of\n>> the three commits. Actually, this left it on top of dev, but suppose I\n>> had created a new branch at dev, cherry-picked the stuff from the old\n>> topic branch, and then deleted the old topic branch.  Now I have a new\n>> topic branch with the rebased changes, albeit with a different branch\n>> name.  Point is, there were no conflicts and the changes were simple, so\n>> cherry-picking each node was clean.\n>>\n>> So, what did the rebase command try to do?  I think it may have\n>> something to do with finding a common root between the topic and dev,\n>> which, due to the merge, was a long way back.  Something like this:\n>>\n>>       o--o--   ...  --o\n>>      /                 \\\n>>     A--...--B--   ... --C--D <== dev\n>>              \\\n>>                   q--r--s  <== topic\n>>\n>>\n>> I was able to cherry-pick q,r,s on top of D without any issues.  So why\n>> did rebase get in such a tizzy?\n> It may help those who know the internals of git-rebase if you supplied the\n> commands you used and your git version.\n> \n> So, you're saying you did\n> \n>    git checkout topic\n>    git rebase dev\n> \n> or the equivalent\n> \n>    git rebase dev topic\n> \n> ?  Are you sure you didn't get the arguments to rebase reversed?\n> \n> -brandon\n> \n\nThat happens very easily: You want to rewrite dev using rebase, so you\ncheck out dev. You want to rebase the topic branch, so you run \"git\nrebase topic\". Very logical, but the wrong way round... The doc is\nclear, though.\n\nA useful mnemonic is that git rebase A B is about the commits A..B (B\ndefaulting to the current branch), and that the new B after rebasing will be\n\nB' = C + (A..B)\n\nwhere C is the value of --onto, which defaults to A. The point of rebase\nis that A + (A..B) does not equal B in general, even though A..B=^A B ;)\n\ngit rebase A does not rewrite/rebase A! I'll think about a concise first\nparagraph for git-rebase.txt.\n\nMichael\n"}]}