Jonathan Nieder [off-list ref] writes:
Example:
o---o---F---X'---G---U [upstream]
\ \
X----Y---M---T [topic]
Suppose the author of the ‘topic’ branch starts from upstream
commit F and makes a few changes. One is applied upstream, and
additionally there is some other useful upstream change, so he
performs a merge to include the upstream updates into topic.
The expected output from ‘cherry’ is:
+ T
+ Y
- X
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?
The expected output from ‘cherry’ is:
+ T
+ Y
+ X
since none of the new commits have been applied upstream since
the fork point.
‘cherry’ cannot distinguish between these two cases, in part because
it does not distinguish between parents in a merge commit.
Now you completely lost me. I guess the biggest reason is you only talk
about "the expected output" without talking about "what it actually
gives". Hence it is unclear what the significant difference "between
these two cases" you are trying to stress here.
Thoughts? Improvements?
I think the actual patch text has the same problem. You say "these
commits" without saying which ones they are; perhaps saing "the commits
represented by asterisks in the picture" or something may help, but I
dunno.
Junio C Hamano wrote:
Jonathan Nieder [off-list ref] writes:
quoted
Example:
o---o---F---X'---G---U [upstream]
\ \
X----Y---M---T [topic]
[...]
quoted
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.