From: John M. Dlugosz <ngnr63q02@sneakemail.com>
Date: Tue, 10 Mar 2009 21:07:27 GMT
Subject: Help understanding "rebase"
Message-ID: <gp6kqj$tkb$1@ger.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