¿Qué hacer si git-am falla con "no coincide con el índice"?

Question

Estoy tratando de aplicar un parche git creado por otra persona con git-format-patch. El parche se hizo contra un compromiso detrás de HEAD, pero según tengo entendido, esto no debería importar. Cuando corro git am 0001.patch, me sale el error:

error: source.c: does not match index

No estoy muy familiarizado con el formato de los parches de Git, pero parece que los índices no coinciden, sin embargo, la fuente hace juego.

¿Cuál es la mejor manera de arreglar esto? ¿Cambia manualmente los índices para que coincidan? ¿O debería git-apply y luego copiar el autor y la información de la descripción cuando confirme?

Answer 1

De J.C. Hamano (Git maintainer) himself, esto es acerca de:

patch applications and merges in a dirty work tree with a clean index.

• A dirty work tree is where you have changes that are not added to the index.
  A work tree that is not dirty is a clean work tree.
• A dirty index is where you have changes already added to it (in other words, " git diff --cached " will report some changes).
  A clean index matches the HEAD.

Con el lanzamiento reciente de Git, puede abortar:

To restore the original branch and stop patching run " git am --abort ".

continuación:

The simplest thing for those who cannot decide may be to stash the changes away for later.

$ git stash save "Random changes that are not ready" 

And then redo " git pull " or " git am ".
" git stash " is the ultimate tool for people who are afraid of commitment.

After redoing " git pull " or " git am ", you can replay the local changes you stashed away:

$ git stash pop 

---

Nota: una fuente de árbol sucio puede ser el escenario autocrlf (como en este msysgit issue 81), así que sure to set that to false.
Otra fuente de discrepancia: core.whitespace setting.

---

El PO menciona en el comentario:

Before trying to run git am I did run git stash , so I don't think that was the problem.
What I ended up doing was running git am -3 patch.patch, then manually fixing the problem, then running ' git am --resolved '.

Nota: en la reciente Git1.7.2 Release Notes:

The message from " git am -3 " has been improved when conflict resolution ended up making the patch a no-op.

Answer 2

para mí que estoy en una de las versiones más antiguas git (CentOS-6 distro).

que era capaz de solucionar el problema haciendo:

• git update-index --refresh
• git am ${patch_filename}

a leer más información sobre por qué esto funciona. Por favor, compruebe the original source here:

"

Estoy un poco sorprendido de que no hemos hecho la 'actualización una vez por adelantado' ya y nadie ha funcionado en esto durante los últimos 5 años Parece que heredé eso. comportamiento de git-applymbox ;-)

Es conveniente actualizar una vez al comienzo y también al reiniciar con "am --resolved".

"