Reputation: 25133
The --cherry-pick
option states:
Omit any commit that introduces the same change as another commit on the “other side”
For next git command I see next tree:
$ git log --graph --decorate --pretty=oneline --abbrev-commit --cherry-mark --boundary --left-right bc2820d...b8d09ce
< bc2820d (openapi3) Merge branch 'openapi3_exception_handling' into openapi3
|\
| = 4e1e0aa Testcase for not_found/exception requests to api
| = b39673d 'not_found' templates should not be probed automatically. Only when fallback
| = a8677df Dump empty schemas and non empty data
| = 27db48f Implemente before_render hook
|/
< aa60f0a Merge branch 'hide_temporal_interface' into openapi3
|\
| = 5dd02f2 Mutate current object after update
| = d58c0ab Install missed modules
|/
| > b8d09ce (xtucha/openapi3) Merge branch 'openapi3_exception_handling' into openapi3
| |\
| | = b6362ad Testcase for not_found/exception requests to api
| | = dc926cc 'not_found' templates should not be probed automatically. Only when fallback
| | = 55dc88d Dump empty schemas and non empty data
| | = 8369185 Implemente before_render hook
| |/
| > c03438d Merge branch 'hide_temporal_interface' into openapi3
| |\
| | = d534cc4 Mutate current object after update
| | = 1b6af27 Install modules required by MonkeyMan
| |/
| > a3b7230 Clarify schema
|/
o f5b06ed Assign some defaults
If I want to see only new commit I add --left-only
option and get merge commits in output.
< bc2820d (openapi3) Merge branch 'openapi3_exception_handling' into
< aa60f0a Merge branch 'hide_temporal_interface' into openapi3
This commits introduce same change as another merge commit on the "other side"
Why these commits are not omitted?
UPD
From the example above I expect only one line of output:
> a3b7230 Clarify schema
Upvotes: 1
Views: 82
Reputation: 488173
The merge itself is considered to be on the left side of the ...
, which is also why in the graph output it is marked with <
rather than >
.
To eliminate merges from git rev-list
or git log
output, add --no-merges
or --max-parents=1
(these are two spellings of the same option).
Edit, re question edit: for "git cherry" and similar purposes, every merge commit is considered unique. That is, it is never the same as any other commit, whether that other commit is or is not a merge. (This happens for multiple internal reasons, the most significant being that a merge commit has more than one parent. To compute a patch ID, Git needs to compare the child commit to a single parent.)
(Edit 2: the above claim might be wrong: git show <merge> | git patch-id
computes a patch ID for the combined diff of the merge. So two merges that produce identical combined diffs may produce identical patch-IDs and hence be considered "the same" by git cherry
. In most cases, though, the combined diff for a merge commit won't match the regular, not-combined, diff for any of the commits it merges, which means that in practice, the merges will appear unique in git cherry
or git rev-list --cherry-mark
or similar.)
Upvotes: 2