Excerpts from Jonathan Nieder's message of Thu Jul 01 14:09:19 -0700 2010: > Example: > > o---o---F---X'---G---U [upstream] > \ \ > X----Y---M---T [topic] > > Suppose the author of the ‘topic’ branch starts from upstream > commit F and makes a few changes. One is applied upstream, and > additionally there is some other useful upstream change, so he > performs a merge to include the upstream updates into topic. > The expected output from ‘cherry’ is: > > + T > + Y > - X > > Consider the author of a different branch, also called ‘topic’, but > this one starts from commit G. Some infrastructure from an existing > branch is needed, so first she merges that. Then she adds her own > commit. The expected output from ‘cherry’ is: > > + T > + Y > + X > > since none of the new commits have been applied upstream since > the fork point. > > ‘cherry’ cannot distinguish between these two cases Thanks for the awesome explanation! (I looked at the code but would not have pulled this understanding.) I would still say the first output is the more reasonable: it's more likely (in my estimate) the wanted result, and in the case where it's not it's at least easily comprehended. Anyway, the doc patch helps, and I would love git cherry --full. Andrew -- 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