From c8bae7493d2f2910b57f13ded012e86bdcfb0532 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 16:47:53 +0200 Subject: Adding upstream version 1:2.39.2. Signed-off-by: Daniel Baumann --- Documentation/git-cherry-pick.txt | 243 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 243 insertions(+) create mode 100644 Documentation/git-cherry-pick.txt (limited to 'Documentation/git-cherry-pick.txt') diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt new file mode 100644 index 0000000..1e8ac9d --- /dev/null +++ b/Documentation/git-cherry-pick.txt @@ -0,0 +1,243 @@ +git-cherry-pick(1) +================== + +NAME +---- +git-cherry-pick - Apply the changes introduced by some existing commits + +SYNOPSIS +-------- +[verse] +'git cherry-pick' [--edit] [-n] [-m ] [-s] [-x] [--ff] + [-S[]] ... +'git cherry-pick' (--continue | --skip | --abort | --quit) + +DESCRIPTION +----------- + +Given one or more existing commits, apply the change each one +introduces, recording a new commit for each. This requires your +working tree to be clean (no modifications from the HEAD commit). + +When it is not obvious how to apply a change, the following +happens: + +1. The current branch and `HEAD` pointer stay at the last commit + successfully made. +2. The `CHERRY_PICK_HEAD` ref is set to point at the commit that + introduced the change that is difficult to apply. +3. Paths in which the change applied cleanly are updated both + in the index file and in your working tree. +4. For conflicting paths, the index file records up to three + versions, as described in the "TRUE MERGE" section of + linkgit:git-merge[1]. The working tree files will include + a description of the conflict bracketed by the usual + conflict markers `<<<<<<<` and `>>>>>>>`. +5. No other modifications are made. + +See linkgit:git-merge[1] for some hints on resolving such +conflicts. + +OPTIONS +------- +...:: + Commits to cherry-pick. + For a more complete list of ways to spell commits, see + linkgit:gitrevisions[7]. + Sets of commits can be passed but no traversal is done by + default, as if the `--no-walk` option was specified, see + linkgit:git-rev-list[1]. Note that specifying a range will + feed all ... arguments to a single revision walk + (see a later example that uses 'maint master..next'). + +-e:: +--edit:: + With this option, 'git cherry-pick' will let you edit the commit + message prior to committing. + +--cleanup=:: + This option determines how the commit message will be cleaned up before + being passed on to the commit machinery. See linkgit:git-commit[1] for more + details. In particular, if the '' is given a value of `scissors`, + scissors will be appended to `MERGE_MSG` before being passed on in the case + of a conflict. + +-x:: + When recording the commit, append a line that says + "(cherry picked from commit ...)" to the original commit + message in order to indicate which commit this change was + cherry-picked from. This is done only for cherry + picks without conflicts. Do not use this option if + you are cherry-picking from your private branch because + the information is useless to the recipient. If on the + other hand you are cherry-picking between two publicly + visible branches (e.g. backporting a fix to a + maintenance branch for an older release from a + development branch), adding this information can be + useful. + +-r:: + It used to be that the command defaulted to do `-x` + described above, and `-r` was to disable it. Now the + default is not to do `-x` so this option is a no-op. + +-m :: +--mainline :: + Usually you cannot cherry-pick a merge because you do not know which + side of the merge should be considered the mainline. This + option specifies the parent number (starting from 1) of + the mainline and allows cherry-pick to replay the change + relative to the specified parent. + +-n:: +--no-commit:: + Usually the command automatically creates a sequence of commits. + This flag applies the changes necessary to cherry-pick + each named commit to your working tree and the index, + without making any commit. In addition, when this + option is used, your index does not have to match the + HEAD commit. The cherry-pick is done against the + beginning state of your index. ++ +This is useful when cherry-picking more than one commits' +effect to your index in a row. + +-s:: +--signoff:: + Add a `Signed-off-by` trailer at the end of the commit message. + See the signoff option in linkgit:git-commit[1] for more information. + +-S[]:: +--gpg-sign[=]:: +--no-gpg-sign:: + GPG-sign commits. The `keyid` argument is optional and + defaults to the committer identity; if specified, it must be + stuck to the option without a space. `--no-gpg-sign` is useful to + countermand both `commit.gpgSign` configuration variable, and + earlier `--gpg-sign`. + +--ff:: + If the current HEAD is the same as the parent of the + cherry-pick'ed commit, then a fast forward to this commit will + be performed. + +--allow-empty:: + By default, cherry-picking an empty commit will fail, + indicating that an explicit invocation of `git commit + --allow-empty` is required. This option overrides that + behavior, allowing empty commits to be preserved automatically + in a cherry-pick. Note that when "--ff" is in effect, empty + commits that meet the "fast-forward" requirement will be kept + even without this option. Note also, that use of this option only + keeps commits that were initially empty (i.e. the commit recorded the + same tree as its parent). Commits which are made empty due to a + previous commit are dropped. To force the inclusion of those commits + use `--keep-redundant-commits`. + +--allow-empty-message:: + 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. + +--keep-redundant-commits:: + If a commit being cherry picked duplicates a commit already in the + current history, it will become empty. By default these + redundant commits cause `cherry-pick` to stop so the user can + examine the commit. This option overrides that behavior and + creates an empty commit object. Implies `--allow-empty`. + +--strategy=:: + Use the given merge strategy. Should only be used once. + See the MERGE STRATEGIES section in linkgit:git-merge[1] + for details. + +-X