Comment appliquer à l'envers une cachette ?

Question

J'ai un petit patch sauvegardé dans ma cachette git. Je l'ai appliqué à ma copie de travail en utilisant la fonction git stash apply . Maintenant, j'aimerais annuler ces changements en appliquant le correctif de manière inverse (un peu comme ce que fait le git revert ferait mais contre la réserve).

Quelqu'un sait-il comment faire ?

Clarification : Il y a d'autres changements dans ma copie de travail. Mon cas particulier est difficile à décrire mais vous pouvez imaginer un code de débogage ou expérimental qui se trouve dans la cachette. Il est maintenant mélangé dans ma copie de travail avec d'autres changements et je voudrais voir l'effet avec et sans les changements de la cachette.

Il ne semble pas que Stash supporte cela actuellement, mais une git stash apply --reverse serait une fonctionnalité intéressante.

Answer 1

Comment appliquer à l'envers une cachette ?

En dehors de ce que les autres ont mentionné, le plus simple est de commencer par faire

git reset HEAD

et ensuite vérifier tous les changements locaux

git checkout .

Answer 2

Vous pouvez appliquer deux commandes

git reset . // pour inverser les fichiers

puis

git checkout . // pour annuler les changements

Answer 3

Vous pouvez suivre l'image que j'ai partagée pour déstocker si vous avez accidentellement touché à la réserve.

Answer 4

En complément de la réponse de @Greg Bacon, dans le cas où des fichiers binaires ont été ajoutés à l'index et faisaient partie de la cachette en utilisant

git stash show -p | git apply --reverse

peut entraîner

error: cannot apply binary patch to '<YOUR_NEW_FILE>' without full index line
error: <YOUR_NEW_FILE>: patch does not apply

Ajout de --binary résout le problème, mais je n'ai malheureusement pas encore compris pourquoi.

 git stash show -p --binary | git apply --reverse

Answer 5

git stash show -p | git apply --reverse

Attention, ce ne serait pas le cas dans tous les cas : " git apply -R " ( homme ) ne traitait pas correctement les correctifs qui touchent deux fois le même chemin, ce qui a été corrigé avec Git 2.30 (Q1 2021).

Ceci est particulièrement pertinent dans le cas d'un correctif qui change un chemin d'un fichier ordinaire en un lien symbolique (et vice versa).

Voir commettre b0f266d (20 oct. 2020) par Jonathan Tan ( jhowtan ) .
(fusionné par Junio C Hamano -- gitster -- en commettre c23cd78 le 02 nov. 2020)

apply : quand -R , ainsi que la liste inversée des sections

Assisté par : Junio C Hamano
Signé par : Jonathan Tan

Un patch changeant un lien symbolique en un fichier est écrit avec 2 sections (dans le code, représenté comme "struct patch") : premièrement, la suppression du lien symbolique, et deuxièmement, la création du fichier.

En appliquant ce patch avec -R les sections sont inversées, donc on obtient : (1) création d'un lien symbolique, puis (2) suppression d'un fichier.

Cela pose un problème lorsque la section "suppression d'un fichier" est cochée, car Git observe que le prétendu fichier n'est pas un fichier mais un lien symbolique, ce qui entraîne un message d'erreur "wrong type".

Ce que nous voulons est : (1) la suppression d'un fichier, puis (2) la création d'un lien symbolique.

Dans le code, ceci est reflété dans le comportement de previous_patch() lorsqu'il est invoqué à partir de check_preimage() lorsque la suppression est vérifiée.
Création puis suppression signifie que lorsque la suppression est vérifiée, previous_patch() renvoie la section de création, ce qui déclenche un conflit de mode entraînant le message d'erreur "wrong type".

Mais suppression puis création signifie que lorsque la suppression est vérifiée, previous_patch() renvoie à NULL Ainsi, le mode de suppression est vérifié par lstat, ce qui est ce que nous voulons.

Il y a aussi d'autres façons dont un patch peut contenir 2 sections faisant référence au même fichier, par exemple, en 7a07841c0b (" git-apply : mieux gérer un patch qui touche le même chemin plus d'une fois", 2008-06-27, Git v1.6.0-rc0 -- fusionner ). " git apply -R " ( homme ) échoue de la même manière, et ce commit fait réussir ce cas.

Par conséquent, lorsque vous construisez la liste des sections, construisez-les dans l'ordre inverse (en ajoutant au début de la liste au lieu de la fin) lorsque -R est adoptée.