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