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