Comme indiqué par @bentolo, vous pouvez supprimer manuellement les fichiers dont il se plaint, changer de branche, puis les ajouter manuellement. Mais je préfère personnellement rester "dans git".
La meilleure façon d'y parvenir est de convertir la réserve en une branche. Une fois que c'est une branche, vous pouvez travailler normalement dans git en utilisant les techniques/outils normaux liés aux branches que vous connaissez et aimez. Il s'agit en fait d'une technique générale utile pour travailler avec des stashs, même si vous n'avez pas l'erreur mentionnée. Elle fonctionne bien parce qu'un stash est vraiment un commit sous les couvertures (voir PS).
Transformation d'une réserve en branche
La procédure suivante crée une branche basée sur le HEAD lorsque la réserve a été créée et applique ensuite la réserve (elle ne la valide pas).
git stash branch STASHBRANCH
Travailler avec la "branche réserve"
Ce que vous faites ensuite dépend de la relation entre la réserve et l'endroit où se trouve votre branche cible (que j'appellerai ORIGINALBRANCH).
Option 1 - Rebasez la branche stash normalement (beaucoup de changements depuis stash)
Si vous avez effectué de nombreuses modifications dans votre ORIGINALBRANCH, il est préférable de traiter STASHBRANCH comme n'importe quelle branche locale. Livrez vos changements dans STASHBRANCH, rebasez-les sur ORIGINALBRANCH, puis basculez sur ORIGINALBRANCH et rebasez/fusionnez les changements de STASHBRANCH dessus. S'il y a des conflits, traitez-les normalement (l'un des avantages de cette approche est que vous pouvez voir et résoudre les conflits).
Option 2 - Réinitialiser la branche d'origine pour qu'elle corresponde à la cachette (changements limités depuis la cachette)
Si vous venez d'empiler tout en gardant certains changements empilés, puis que vous avez commis, et que tout ce que vous voulez faire est de récupérer les changements supplémentaires qui n'étaient pas empilés lorsque vous avez empilé, vous pouvez faire ce qui suit. Cela retournera à votre branche originale et à votre index sans changer votre copie de travail. Le résultat final sera vos changements supplémentaires dans votre copie de travail.
git symbolic-ref HEAD refs/heads/ORIGINALBRANCH
git reset
Contexte
Les cachettes sont des commits comme des branches/étiquettes (pas des correctifs).
PS : Il est tentant de considérer un stash comme un patch (tout comme il est tentant de considérer un commit comme un patch), mais un stash est en fait un commit par rapport au HEAD lorsqu'il a été créé. Lorsque vous appliquez/pop, vous faites quelque chose de similaire à une cueillette dans votre branche actuelle. Gardez à l'esprit que les branches et les étiquettes ne sont en fait que des références aux livraisons, de sorte qu'à bien des égards, les stashs, les branches et les étiquettes ne sont que des façons différentes de pointer vers une livraison (et son historique).
Parfois nécessaire même si vous n'avez pas modifié le répertoire de travail
PPS, vous aurez peut-être besoin de cette technique après avoir utilisé stash avec --patch et/ou --include-untracked. Même sans changer les répertoires de travail, ces options peuvent parfois créer un stash que vous ne pouvez pas simplement appliquer à nouveau. Je dois admettre que je ne comprends pas très bien pourquoi. Voir http://git.661346.n2.nabble.com/stash-refuses-to-pop-td7453780.html pour une discussion.
