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
--
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
