By default, cherry-picking a commit with an empty message will fail.
This option overrides that behavior, allowing commits with empty
messages to be cherry picked.
--empty=(drop|keep|stop)::
How to handle commits being cherry-picked that are redundant with
changes already in the current history.
+
--
`drop`;;
The commit will be dropped.
`keep`;;
The commit will be kept. Implies `--allow-empty`.
`stop`;;
The cherry-pick will stop when the commit is applied, allowing
you to examine the commit. This is the default behavior.
--
+
Note that `--empty=drop` and `--empty=stop` only specify how to handle a
commit that was not initially empty, but rather became empty due to a previous
commit. Commits that were initially empty will still cause the cherry-pick to
fail unless one of `--empty=keep` or `--allow-empty` are specified.
+
--keep-redundant-commits::
Deprecated synonym for `--empty=keep`.
--strategy=<strategy>::
Use the given merge strategy. Should only be used once.
See the MERGE STRATEGIES section in linkgit:git-merge[1]
for details.
-X<option>::
--strategy-option=<option>::
Pass the merge strategy-specific option through to the
merge strategy. See linkgit:git-merge[1] for details.
include::rerere-options.adoc[]
SEQUENCER SUBCOMMANDS
---------------------
include::sequencer.adoc[]
EXAMPLES
--------
`git cherry-pick master`::
Apply the change introduced by the commit at the tip of the
master branch and create a new commit with this change.
`git cherry-pick ..master`::
`git cherry-pick ^HEAD master`::
Apply the changes introduced by all commits that are ancestors
of master but not of HEAD to produce new commits.
`git cherry-pick maint next ^master`::
`git cherry-pick maint master..next`::
Apply the changes introduced by all commits that are
ancestors of maint or next, but not master or any of its
ancestors. Note that the latter does not mean `maint` and
everything between `master` and `next`; specifically,
`maint` will not be used if it is included in `master`.
`git cherry-pick