Re: Cherry woes

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 12, 2009, 17:57 UTC
Message-ID: <32541b130905121057s19f9dd42h566a017d47bfe865@mail.gmail.com>
In-Reply-To: <4A097659.4060507@drmicha.warpmail.net>

On Tue, May 12, 2009 at 9:15 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 5 quoted lines

> 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