Spaces:
Sleeping
Sleeping
File size: 5,263 Bytes
1d777c4 |
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 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 |
'\" t
.\" Title: git-cherry
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
.\" Date: 04/24/2023
.\" Manual: Git Manual
.\" Source: Git 2.40.1
.\" Language: English
.\"
.TH "GIT\-CHERRY" "1" "04/24/2023" "Git 2\&.40\&.1" "Git Manual"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
git-cherry \- Find commits yet to be applied to upstream
.SH "SYNOPSIS"
.sp
.nf
\fIgit cherry\fR [\-v] [<upstream> [<head> [<limit>]]]
.fi
.sp
.SH "DESCRIPTION"
.sp
Determine whether there are commits in \fB<head>\&.\&.<upstream>\fR that are equivalent to those in the range \fB<limit>\&.\&.<head>\fR\&.
.sp
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 \fBgit-cherry-pick\fR(1), \fBgit-am\fR(1) or \fBgit-rebase\fR(1)\&.
.sp
Outputs the SHA1 of every commit in \fB<limit>\&.\&.<head>\fR, prefixed with \fB\-\fR for commits that have an equivalent in <upstream>, and \fB+\fR for commits that do not\&.
.SH "OPTIONS"
.PP
\-v
.RS 4
Show the commit subjects next to the SHA1s\&.
.RE
.PP
<upstream>
.RS 4
Upstream branch to search for equivalent commits\&. Defaults to the upstream branch of HEAD\&.
.RE
.PP
<head>
.RS 4
Working branch; defaults to HEAD\&.
.RE
.PP
<limit>
.RS 4
Do not report commits up to (and including) limit\&.
.RE
.SH "EXAMPLES"
.SS "Patch workflows"
.sp
git\-cherry is frequently used in patch\-based workflows (see \fBgitworkflows\fR(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:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git checkout \-b topic origin/master
# work and create some commits
$ git format\-patch origin/master
$ git send\-email \&.\&.\&. 00*
.fi
.if n \{\
.RE
.\}
.sp
.sp
Later, you can see whether your changes have been applied by saying (still on \fBtopic\fR):
.sp
.if n \{\
.RS 4
.\}
.nf
$ git fetch # update your notion of origin/master
$ git cherry \-v
.fi
.if n \{\
.RE
.\}
.sp
.SS "Concrete example"
.sp
In a situation where topic consisted of three commits, and the maintainer applied two of them, the situation might look like:
.sp
.if n \{\
.RS 4
.\}
.nf
$ 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
.fi
.if n \{\
.RE
.\}
.sp
.sp
In such cases, git\-cherry shows a concise summary of what has yet to be applied:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git cherry origin/master topic
\- cccc000\&.\&.\&. commit C
+ bbbb000\&.\&.\&. commit B
\- aaaa000\&.\&.\&. commit A
.fi
.if n \{\
.RE
.\}
.sp
.sp
Here, we see that the commits A and C (marked with \fB\-\fR) can be dropped from your \fBtopic\fR branch when you rebase it on top of \fBorigin/master\fR, while the commit B (marked with \fB+\fR) still needs to be kept so that it will be sent to be applied to \fBorigin/master\fR\&.
.SS "Using a limit"
.sp
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:
.sp
.if n \{\
.RS 4
.\}
.nf
$ 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
.fi
.if n \{\
.RE
.\}
.sp
.sp
By specifying \fBbase\fR as the limit, you can avoid listing commits between \fBbase\fR and \fBtopic\fR:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git cherry origin/master topic base
\- cccc000\&.\&.\&. commit C
+ bbbb000\&.\&.\&. commit B
\- aaaa000\&.\&.\&. commit A
.fi
.if n \{\
.RE
.\}
.sp
.SH "SEE ALSO"
.sp
\fBgit-patch-id\fR(1)
.SH "GIT"
.sp
Part of the \fBgit\fR(1) suite
|