Cherry woes

Cherry woes

[Michael J Gruber]

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

Re: Cherry woes

[Avery Pennarun]

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