Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream

[Andrew Pimlott <andrew@pimlott.net>]

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