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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 2, 2010, 00:51 UTC
Message-ID: <20100702005147.GA5962@burratino>
In-Reply-To: <7vbpaq3glt.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 5 quoted lines

>> Example:
>>
>>  o---o---F---X'---G---U [upstream]
>>           \        \
>>            X----Y---M---T [topic]

[...]

Show 14 quoted lines

>> 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.