Les commits à picorer. Pour une liste plus complète des façons d’épeler les commits, voir gitrevisions[7]. Des ensembles de commits peuvent être passés mais aucune traversée n’est faite par défaut, comme si l’option --no-walk était spécifiée, voir git-rev-list[1]. Notez que la spécification d’une plage alimentera tous les arguments <commit>…​ à un seul parcours de révision (voir un exemple plus bas qui utilise maint master…​next).

Avec cette option, git cherry-pick vous permettra de modifier le message de validation avant de valider.

Cette option détermine comment le message de valiation sera nettoyé avant d’être transmis à la machine de commit. Voir git-commit[1] pour plus de détails. En particulier, si la valeur de <mode> est scissors, les ciseaux seront ajoutés à MERGE_MSG avant d’être transmis dans le cas d’un conflit.

Lors de l’enregistrement du commit, ajouter une ligne qui ajoute "(cherry pick from commit …​)" au message de commit original afin d’indiquer de quel commit ce changement a été picoré. Ceci est fait uniquement pour les picorages sans conflits. N’utilisez pas cette option si vous faites du picorage depuis votre branche privée car l’information est inutile pour le destinataire. En revanche, si vous faites du picorage entre deux branches visibles publiquement (par exemple, le rétroportage d’un correctif dans une branche de maintenance d’une ancienne version à partir d’une branche de développement), l’ajout de cette information peut être utile.

Avant, la commande faisait par défaut -x comme décrit ci-dessus, et -r permettait de la désactiver. Maintenant, le défaut est de ne pas faire -x, donc cette option est un no-op.

Habituellement, vous ne pouvez pas picorer une fusion parce que vous ne savez pas quel côté de la fusion doit être considéré comme la ligne principale. Cette option spécifie le numéro du parent (à partir de 1) de la ligne principale et permet à cherry-pick de rejouer la modification par rapport au parent spécifié.

Habituellement, la commande crée automatiquement une séquence de commits. Cette option applique les changements nécessaires pour sélectionner chaque commit nommé à votre arbre de travail et à l’index, sans faire aucun commit. De plus, lorsque cette option est utilisée, votre index ne doit pas nécessairement correspondre au commit HEAD. Le picorage est fait par rapport à l’état initial de votre index.

Ajouter une ligne terminale Signed-off-by au message de commit. Référez-vous à l’option de contre-signature dans git-commit[1] pour plus d’information.

Signer les commits avec GPG. L’argument idclé est optionnel avec par défaut l’identité du validateur ; si spécifiée, elle doit être collée à l’option sans aucun espace. --no-gpg-sign est utile pour annuler l’effet de la variable de configuration commit.gpgSign ainsi que tout --gpg-sign précédent.

Si le HEAD actuel est le même que le parent du commit picoré, alors une avance rapide sur ce commit sera effectuée.

Par défaut, le picorage d’un commit vide échouera, indiquant qu’une invocation explicite de git commit --allow-empty est nécessaire. Cette option surcharge ce comportement, permettant aux commits vides d’être préservés automatiquement dans un picorage. Notez que lorsque "--ff" est en vigueur, les commits vides qui répondent à l’exigence d'"avance rapide" seront conservés même sans cette option. Notez également que l’utilisation de cette option ne conserve que les commits qui étaient initialement vides (c’est-à-dire que le commit a enregistré le même arbre que son parent). Les commits qui sont rendus vides à cause d’un commit précédent sont abandonnés. Pour forcer l’inclusion de ces commits, utilisez --keep-redundant-commits.

Par défaut, le picorage d’un commit avec un message vide échouera. Cette option annule ce comportement, permettant aux commits avec des messages vides d’être picorés.

Si un commit faisant l’objet d’un picorage duplique un commit déjà présent dans l’historique courant, celui-ci deviendra vide. Par défaut, ces commits redondants provoquent l’arrêt de cherry-pick pour que l’utilisateur puisse examiner le commit. Cette option surcharge ce comportement et crée un objet commit vide. Implique --allow-empty.

Utilise la stratégie de fusion donnée. Ne devrait être utilisée qu’une seule fois. Voir la section STRATÉGIES DE FUSION dans git-merge[1] pour plus de détails.

Passer l’option spécifique de stratégie de fusion à la stratégie de fusion. Voir git-merge[1] pour plus de détails.

Permettre au mécanisme rerere de mettre à jour l’index avec le résultat de la résolution automatique des conflits si possible.

Applique la modification introduite par le commit au sommet de la branche master et créer un nouveau commit avec cette modification.

Applique les modifications introduites par tous les commits qui sont des ancêtres de master mais pas de HEAD pour produire de nouveaux commits.

Applique les modifications introduites par tous les commits qui sont des ancêtres de maint ou next, mais pas master ni aucun de ses ancêtres. Notez que ce dernier ne signifie pas maint et tout ce qui se trouve entre master et next ; spécifiquement, maint ne sera pas utilisé s’il est inclus dans master.

Applique les modifications introduites par les cinquième et troisième derniers commits pointés par master et crée 2 nouveaux commits avec ces modifications.

Applique à l’arbre de travail et à l’index les modifications introduites par l’avant-dernier commit pointé par master et par le dernier commit pointé par next, mais ne crée aucun commit avec ces modifications.

Si l’historique est linéaire et que HEAD est un ancêtre de next, met à jour l’arbre de travail et avance le pointeur HEAD pour qu’il corresponde à next. Sinon, applique les modifications introduites par les commits qui sont dans next mais pas HEAD à la branche courante, en créant un nouveau commit pour chaque nouvelle modification.

Applique les modifications introduites par tous les commits de la branche master qui ont touché README, à l’arbre de travail et à l’index, afin que le résultat puisse être inspecté et transformé en un seul nouveau commit si cela convient.