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

From: Andrew Pimlott <andrew@pimlott.net>
Date: Jul 1, 2010, 21:33 UTC
Message-ID: <1278019489-sup-4929@pimlott.net>
In-Reply-To: <20100701210919.GA4283@burratino>

Excerpts from Jonathan Nieder's message of Thu Jul 01 14:09:19 -0700 2010:

Show 29 quoted lines

> 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