146 lines
3.5 KiB
Text
146 lines
3.5 KiB
Text
|
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
|