Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream

[Jonathan Nieder <jrnieder@gmail.com>]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> Example:
>>
>>  o---o---F---X'---G---U [upstream]
>>           \        \
>>            X----Y---M---T [topic]
[...]
>> Consider the author of a different branch, also called ‘topic’, but
>> this one starts from commit G.  Some infrastructure from an existing 
>> branch is needed, so first she merges that.  Then she adds her own
>> commit.
>
> Sorry, but it is unclear to me what kind of history you have in mind at
> this point.  What "existing branch" are you talking about?  Presumably it
> is not the [topic] in an earlier example, nor it is [upstream] right?
> 
> o---o---o---o----G-------.---U [upstream]
>                   \       \ 
>                    X---Y---M---T
> 
> Something like this?

Sorry for the lack of clarity.  The "existing branch" was the history
ending at commit Y in the original picture.  The resulting topic would
have the shape of the branch labelled [topic] in my diagram.

And except for the shapes being the same, this has nothing to do with
the earlier example.

What I was trying to get at with the two examples is that in histories
like the above, the concept of "fork point" is not well defined.
Where did topic fork from upstream?  It could have been at G, or F, or
any other merge-base of upstream and topic for that matter; the
recorded history does not give enough information to say.

The choice of fork point might look like it is only for optimization,
but it affects the semantics, too.

Example: reviving a reverted patch

 ... o---F---P---R---G---o [upstream]
                      \
                       P' [alice]

Upstream, a certain patch (P) was accepted, found to introduce horrible
problems, and then reverted (R).  Patch submitter Alice still believes
that is a good patch, though, so she creates a branch to start work on
it, cherry-picking the change (P').  ‘git cherry’ correctly reports
P' as not merged upstream; that it has the same patch-id as commit P
is simply irrelevant.

 $ git cherry
 + P'

Alice might merge a branch with a fork point that does not have P as
an ancestor:

 ... o---o---P---R---G---o [upstream]
                      \ /
                       x
                      / \
                     o   P'
                    /     \
   ... o---o---o---F---o---M [alice]

How can ‘git cherry’ tell that the fork point was G?  That
knowledge determines whether P' should be considered to be merged
upstream or not:

 * If the fork point was F, then the patch for P' has been applied
   upstream since then (indirectly through the merge of G).

 * If the fork point is G, then the patch for P' was upstream all
   along, and P' has no upstream analog since then.

In reality, ‘git cherry’ does not choose; instead of doing arithmetic
based on fork points, it just says _no_ commit reachable from the tip
of alice can be used as evidence that a patch from alice has been
merged.

Plenty of other heuristics are possible, but it is hard to find a
more intuitive efficient one.  I suspect I would find it useful to be
able to explicitly set a commit ‘prefork’ and examine all commits
prefork..upstream in the search for evidence that a patch has been
merged.