|
|
|
|
git-cherry(1)
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
Documentation: revamp git-cherry(1)
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
11 years ago
|
|
|
git-cherry - Find commits yet to be applied to upstream
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
|
|
|
|
[verse]
|
|
|
|
|
'git cherry' [-v] [<upstream> [<head> [<limit>]]]
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
Documentation: revamp git-cherry(1)
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
11 years ago
|
|
|
Determine whether there are commits in `<head>..<upstream>` that are
|
|
|
|
|
equivalent to those in the range `<limit>..<head>`.
|
|
|
|
|
|
Documentation: revamp git-cherry(1)
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
11 years ago
|
|
|
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].
|
|
|
|
|
|
Documentation: revamp git-cherry(1)
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
11 years ago
|
|
|
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::
|
Documentation: revamp git-cherry(1)
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
11 years ago
|
|
|
Show the commit subjects next to the SHA1s.
|
|
|
|
|
|
|
|
|
|
<upstream>::
|
Documentation: revamp git-cherry(1)
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
11 years ago
|
|
|
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.
|
|
|
|
|
|
Documentation: revamp git-cherry(1)
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
11 years ago
|
|
|
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
|
