Cherry woes

Hi there

I encountered a misfeature of cherry or misuse of it by myself... Also, the behaviour is not quite what the doc suggests. The script below generates the following DAG:

*   05f4f8c (refs/heads/master) Merge branch 'upstream'
|\
| * 2c8fad1 (refs/heads/upstream) add a
* | df7b5e4 Add a
|/
* 6bdebf5 init

Naively, one would say that master and upstream contain one commit each which differ but their patch-ids coincide (see below). That's the same situation before as well as after the merge.

But calling "git cherry -v upstream" when on the master branch gives different results:

Before merge:
- df7b5e472d9a23d02943b331a7dc9ec638f44b33 Add a
Merge made by recursive.
After merge:
+ df7b5e472d9a23d02943b331a7dc9ec638f44b33 Add a

Of course master contains both 2c8fad1 and df7b5e4, and upstream only the latter (Did I say "naively"?). But still upstream contains a commit which is patch-equivalent to 2c8fad1, and which git cherry does not find.

The point is that "git cherry upstream head" looks at each commit in upstream..head and checks whether there is an equivalent patch in head..upstream. (This differs from the doc which says fork-point..head resp. fork-point..upstream.)

In the DAG above, all is well when head is master^ (df7b5e4), i.e. before the merge, but head..upstream is empty after the merge.

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.

Michael

--->%--- #!/bin/bash

rm -Rf cherrybug mkdir cherrybug && cd cherrybug && git init echo a > a && git add a && git commit -m init git checkout -b upstream echo b >> a && git add a && git commit -m "add a" git checkout master echo b >> a && git add a && git commit -m "Add a" echo "Before merge:" git cherry -v upstream git merge upstream echo "After merge:" git cherry -v upstream

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

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