Git: impossible d'annuler les modifications locales (erreur: le chemin… n'est pas fusionné)

338

J'ai un état d'arbre de travail suivant

$ git status foo/bar.txt
# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       deleted by us:      foo/bar.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Le fichier foo/bar.txtest là et je veux le remettre à "l'état inchangé" (similaire à "svn revert"):

$ git checkout HEAD foo/bar.txt
error: path 'foo/bar.txt' is unmerged
$ git reset HEAD foo/bar.txt
Unstaged changes after reset:
M       foo/bar.txt

Maintenant, cela devient déroutant:

$ git status foo/bar.txt
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo/bar.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   foo/bar.txt
#

Le même fichier dans les deux sections, nouveau et modifié? Que devrais-je faire?

git git-checkout git-reset

— mklhmnn
source

7

J'aimerais que quelqu'un puisse expliquer comment nous nous retrouvons dans cette situation, pourquoi cela se produit et pourquoi la solution fonctionne.

— Marcos Dione

1

Je suis entré dans cette situation quand j'ai sauté ma cachette après un rebase qui m'a plongé dans un conflit de fusion (la cachette fait une fusion) .... Pour le résoudre, j'ai fait un "checkout --theirs" .... apparemment mon les changements étaient toujours là .... pour supprimer ceux-ci ... J'ai essayé une nouvelle fois de vérifier le fichier ... c'est quand j'ai vu l'erreur ci-dessus.

— Arindam Roychowdhury

558

Vous l'avez mal fait. Vous devez d'abord réinitialiser, annuler la mise en scène du fichier, puis retirer, pour annuler les modifications locales.

Essaye ça:

$ git reset foo/bar.txt
$ git checkout foo/bar.txt

— Igor Zevaka
source

Merci; travaillé comme un charme! J'ai dû valider ( pas avec l'argument -a, les modifications pertinentes étaient déjà mises en scène), puis j'ai pu pousser / tirer comme d'habitude.

— Patrick

18

Pour moi, cela nécessitait: <br/> $ git reset - foo / bar.txt <br/> $ git checkout - foo / bar.txt <br/> (Notez le "-" supplémentaire entre les deux)

— Jan

4

La bonne syntaxe est "git reset HEAD file1 file2 ..." puis "git checkout - file1 file2 ..."

— Thomas Decaux

1

C'est toujours amusant quand la réponse la plus votée dit simplement "vous vous trompez" :)

— nathanchere

4

Une explication (sur ce que font les choses) aurait été formidable…

— Kissaki

52

Cela a parfaitement fonctionné pour moi:

$ git reset -- foo/bar.txt
$ git checkout foo/bar.txt

— Steffi
source

14

git checkout origin/[branch] .
git status

// Notez le point (.) À la fin. Et tout ira bien

— Joe Hyde
source

-2

git checkout foo/bar.txt

avez-vous essayé cela? (sans mot clé HEAD)

Je reviens généralement à mes modifications de cette façon.

— zed_0xff
source

1

Erreur typique lors de l'essai d'un checkoutau milieu d'une fusion: $ git co path/to/file= résultat => error: path 'path/to/file' is unmerged => donc, exécutez d'abord:, $ git reset path/to/filepuis le git checkout path/to/filedevrait fonctionner.

— michael

2

Ne pas spécifier HEAD fera extraire git checkout de l'index, ce qui est une opération plus faible (la source de contenu est l'index plutôt que HEAD). De plus, je ne pense pas que cela fasse une différence dans ce cas - avec le problème spécifique posé par la question. Avez- vous essayé cela?

— Kissaki

-4

Je trouve git stash très utile pour la gestion temporelle de tous les états `` sales ''.

— takhin
source

4

Si vous le trouvez utile, veuillez expliquer comment cela pourrait aider dans ce cas concret. Comment l'utiliseriez-vous ici?

— Kissaki