1GIT-CHERRY(1) Git Manual GIT-CHERRY(1)
2
6 git-cherry - Find commits yet to be applied to upstream
7
9 git cherry [-v] [<upstream> [<head> [<limit>]]]
10
12 Determine whether there are commits in <head>..<upstream> that are
13 equivalent to those in the range <limit>..<head>.
14 The equivalence test is based on the diff, after removing whitespace
16 and line numbers. git-cherry therefore detects when commits have been
17 "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).
18 Outputs the SHA1 of every commit in <limit>..<head>, prefixed with -
20 for commits that have an equivalent in <upstream>, and + for commits
21 that do not.
22
24 -v
25 Show the commit subjects next to the SHA1s.
26 <upstream>
28 Upstream branch to search for equivalent commits. Defaults to the
29 upstream branch of HEAD.
30 <head>
32 Working branch; defaults to HEAD.
33 <limit>
35 Do not report commits up to (and including) limit.
36
38 Patch workflows
39 git-cherry is frequently used in patch-based workflows (see
40 gitworkflows(7)) to determine if a series of patches has been applied
41 by the upstream maintainer. In such a workflow you might create and
42 send a topic branch like this:
43 $ git checkout -b topic origin/master
45 # work and create some commits
46 $ git format-patch origin/master
47 $ git send-email ... 00*
48 Later, you can see whether your changes have been applied by saying
50 (still on topic):
51 $ git fetch # update your notion of origin/master
53 $ git cherry -v
54 Concrete example
56 In a situation where topic consisted of three commits, and the
57 maintainer applied two of them, the situation might look like:
58 $ git log --graph --oneline --decorate --boundary origin/master...topic
60 * 7654321 (origin/master) upstream tip commit
61 [... snip some other commits ...]
62 * cccc111 cherry-pick of C
63 * aaaa111 cherry-pick of A
64 [... snip a lot more that has happened ...]
65 | * cccc000 (topic) commit C
66 | * bbbb000 commit B
67 | * aaaa000 commit A
68 |/
69 o 1234567 branch point
70 In such cases, git-cherry shows a concise summary of what has yet to be
72 applied:
73 $ git cherry origin/master topic
75 - cccc000... commit C
76 + bbbb000... commit B
77 - aaaa000... commit A
78 Here, we see that the commits A and C (marked with -) can be dropped
80 from your topic branch when you rebase it on top of origin/master,
81 while the commit B (marked with +) still needs to be kept so that it
82 will be sent to be applied to origin/master.
83 Using a limit
85 The optional <limit> is useful in cases where your topic is based on
86 other work that is not in upstream. Expanding on the previous example,
87 this might look like:
88 $ git log --graph --oneline --decorate --boundary origin/master...topic
90 * 7654321 (origin/master) upstream tip commit
91 [... snip some other commits ...]
92 * cccc111 cherry-pick of C
93 * aaaa111 cherry-pick of A
94 [... snip a lot more that has happened ...]
95 | * cccc000 (topic) commit C
96 | * bbbb000 commit B
97 | * aaaa000 commit A
98 | * 0000fff (base) unpublished stuff F
99 [... snip ...]
100 | * 0000aaa unpublished stuff A
101 |/
102 o 1234567 merge-base between upstream and topic
103 By specifying base as the limit, you can avoid listing commits between
105 base and topic:
106 $ git cherry origin/master topic base
108 - cccc000... commit C
109 + bbbb000... commit B
110 - aaaa000... commit A
111
113 git-patch-id(1)
114
116 Part of the git(1) suite
117Git 2.33.1 2021-10-12 GIT-CHERRY(1)