Re: Cherry woes

[Avery Pennarun <apenwarr@gmail.com>]

On Tue, May 12, 2009 at 9:15 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Now, adjusting the doc is easy, but I still feel that cherry does not
> give the most useful info in the situation at hand. But how would I find
> a better lower boundary for the range ..upstream? merge-base of master
> and upstream is upstream so that doesn't cut it. So I'm wondering what
> the right approach is and whether anyone cares.

I think the problem is that there's no well-defined "furthest back"
place where a particular patch might already exist in upstream.
Perhaps it was placed in upstream three years ago.

My guess is git-cherry was designed for a primarily rebase-like
workflow.  In that case, you would *never* merge between the two
branches in question, so the fork-point (ie. merge-base) would be the
right thing to use, as git-cherry already seems to do.

Aha, and the git changelog seems to support this theory, as we can see
by the first mention of git-cherry in
93c36dcd0a4f6373e3a02a8505046801106ddb85:

    [PATCH] git-cherry: find commits not merged upstream.

    The git-cherry command helps the git-rebase script by finding
    commits that have not been merged upstream.  Commits already
    included in upstream are prefixed with '-' (meaning "drop from
    my local pull"), while commits missing from upstream are
    prefixed with '+' (meaning "add to the updated upstream").

So my conclusion: git cherry is not really compatible with git merge.
Its man page could probably use a clarification to this effect.

Have fun,

Avery