On Tue, May 12, 2009 at 9:15 AM, Michael J Gruber
<git@xxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html