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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
