git cherry-pick ne fonctionne pas

111

J'essaye de choisir un commit de master et de l'introduire dans la branche de production actuelle. Cependant, lorsque j'exécute git cherry-pick <SHA-hash>, je reçois juste ce message:

# On branch prod_20110801
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#   site/test-result/
 nothing added to commit but untracked files present (use "git add" to track)
 The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'

Remarque: j'ai essayé de faire une réinitialisation et une réinitialisation --hard HEAD ^, et aucun des deux n'a semblé changer quoi que ce soit.

Je ne comprends pas pourquoi cela ne fonctionne pas pour moi.

Tout aperçu, conseil ou idée sur la façon de résoudre ce problème serait utile ~!

git branching-and-merging cherry-pick Jay Taylor
la source
Cela m'est arrivé lorsque j'ai accidentellement essayé de choisir le mauvais commit. Cela se produit parfois lors de l'utilisation de gitk.
cst1992

Réponses:

142

Git résout le cherry-pick comme un no-op - tous les changements introduits par ce commit ont été introduits par un commit sur votre branche actuelle. (Ou c'est ce que pense Git, de toute façon.) Vérifiez que le commit que vous sélectionnez à la cerise n'a pas déjà été fusionné d'une manière ou d'une autre, en tant que correctif approprié de fusion, de rebase / sélection de cerise ou de patch au coup par coup. (Utilisez git show <commit-id>pour voir le diff.)

cdhowie
la source
16
Merci pour vos conseils, il s'avère que le choix de la cerise a déjà eu lieu et que je n'ai plus qu'à le pousser sur github.
Jay Taylor
Bon, je ne savais pas qu'il vérifiait le contenu des fichiers avec le commit-id. J'ai cherché le commit-id dans le journal et je n'ai pas pu le trouver. il s'est avéré qu'il était déjà fusionné.
mparaz
Malheureusement, ce n'est pas la seule raison de problème en question. J'ai exactement la même situation lorsque j'ai eu un commit, qui annule un commit précédent, et quand je l'ai choisi avec soin sur une autre branche, dont l'historique n'avait pas que les changements étaient annulés (c'est-à-dire que je n'avais pas choisi de cerise sur ce commit rétabli ). Bien sûr, c'est ma faute. Mais dans ce cas, on s'attend à ce que git échoue avec un statut de conflit, au lieu d'essayer d'être trop intelligent, ce qui entraîne un utilisateur confus.
Artem Pisarenko
Cela peut se produire si vous annulez un commit de fusion et que le commit à sélectionner avec soin réside sur la branche rétablie.
mat
11

Dans mon cas, cela me rendait fou, car il était tout à fait évident que le commit spécifique que je voulais sélectionner n'avait pas été fusionné dans ma branche actuelle.

Il s'avère que quelqu'un avait déjà choisi le commit une semaine auparavant. Les changements , mais pas le SHA spécifique, étaient déjà dans ma branche actuelle et je ne les avais pas remarqués.

Vérifiez le (s) fichier (s) que vous essayez de sélectionner. S'ils ont déjà les modifications, une version du commit a déjà été choisie ou ajoutée d'une autre manière. Il n'est donc pas nécessaire de le cueillir à nouveau.

pkamb
la source
Je suis presque sûr que le commit spécifique n'est jamais dans votre branche quand il a été introduit par un choix de cerises, parce que le choix de cerises sera un nouveau hachage, non? Ou suis-je mal compris?
msouth
@msouth Ce que j'ai initialement retenu des autres réponses était "le commit était déjà fusionné", mais je pouvais voir qu'il n'était pas dans ma branche. Vous avez raison sur le fait que le choix des cerises est toujours un nouveau SHA.
pkamb
Ouais, je pensais "le commit spécifique, comme identifié par le hachage", quand j'ai tapé ça. Ma langue était imprécise. Je regarde souvent en arrière à travers la sortie de git log --graph --pretty --decorate --onelinepour voir si un SHA donné est dans ma branche ou non. Voir ma réponse ci-dessous sur la façon dont vous pouvez également vous mêler en pensant que le message de validation est indicatif du changement - il y a une situation où ce n'est pas le cas, et c'est ce qui m'a amené à cette question à l'origine. Le cerveau a tendance à faire ces raccourcis et il peut parfois revenir vous mordre.
msouth
6

Notez également que l'ajout d'un fichier vide (par exemple .gitkeep) à l'arborescence est considéré par cherry-pick comme un commit vide.

Neamar
la source
Dans mon cas, j'avais un commit de retour (qui annulait lui-même un commit vide) avant mon essai de sélection, donc je suppose que tout ce qui est vide provoquera probablement l'apparition de ce message.
lidkxx
3

Alors, voici encore une autre situation déroutante où cela peut survenir: j'ai eu ce qui suit:

Capture d'écran de git log

J'essayais de choisir 9a7b12e qui n'est apparemment rien - il a même essayé de me dire sur cette ligne dans la sortie du journal git que 4497428 était ce que je voulais vraiment. (Ce que j'ai fait, c'est juste chercher le message de validation et attraper le premier hachage que j'ai vu qui l'avait). Quoi qu'il en soit, je veux juste faire savoir aux gens qu'il existe un autre moyen de se faire tromper en essayant de choisir un no op.

msouth
la source
10
Pas très utile pour vous de voter sans explication - c'est la reproduction exacte d'un problème que j'ai eu qui m'a amené à trouver cette question lors de ma recherche. Si vous avez une recommandation pour améliorer cela, veuillez me le dire dans les commentaires au lieu de simplement voter contre.
msouth