git-apply falla misteriosamente, ¿cómo soluciono/soluciono problemas?

Question

git-apply falla misteriosamente, ¿cómo soluciono/soluciono problemas?

Actualmente estoy tratando de revisar el estilo de código en las PRs de un repositorio (github), y quiero entregar parches a los remitentes con los que puedan arreglar fácilmente el estilo de código. Con este fin, estoy tirando hacia abajo su PR, ejecutar nuestro script uncrustify sobre él para corregir cualquier error de estilo, y quiero crear un .archivo de parche que pueden aplicar fácilmente. Sin embargo, se rompe constantemente en algunos archivos.

Lo hago (git versión 1.7.10.4 con core.autocrlf=input, core.filemode=false):

$ git checkout pr-branch
$ git log -1 (shows: commit dbb8d3f)
$ git status (nothing to commit, working directory clean)
$ <run the code styler script, which modifies some files>
$ git diff > ../style.patch (so the patch file lands outside the repo)
$ git reset --hard HEAD (to simulate the situation at the submitter's end)
$ git log -1 (shows: commit dbb8d3f)
$ git status (nothing to commit, working directory clean, so we are where we started)
$ git apply ../style.patch
error: patch failed: somefile.cpp:195
error: somefile.cpp: patch does not apply (same output using the --check option)

Esto solo se aplica a algunos archivos, no todos. No se cómo solucionar esto, es decir, cómo hacer que git me diga exactamente dónde va mal-solo me dice un pedazo# cuando cavo, pero eso sigue siendo bastante grande.

Lo que he intentado hasta ahora (sin éxito):

apply --reverse, apply --whitespace=nowarn
diff HEAD en lugar de diff solo
haga un commit ficticio (¡el commit funciona sin problema!), use format-patch, elimine la confirmación ficticia, aplique el parche con git-am con o sin -3, o aplique con git-apply
Tenga el archivo de parche en el directorio local en lugar de uno arriba (agarrando a un clavo ardiendo, aquí)
Compruebe las páginas de manual de git-diff,-apply,- format-patch,-am para cualquier cosa útil
parche con el comando linux patch
....

No se que podría estar mal con la diferencia. Los espacios en blanco solo deberían advertir, ¿verdad? En cualquier caso, no quiero ignorarlos, ya que es una solución de estilo que obviamente implica espacios en blanco.

¿Cómo puedo ¿arreglar / diagnosticar esto o incluso averiguar dónde se rescata exactamente? ¿Ayudaría si publicara la diferencia de uno de los archivos del culpable? Lo que me desconcierta también es que el commit funciona sin problema, pero el parche creado a partir del commit no lo hace??

Después de luchar con esto durante varias horas estoy al final de mi conocimiento...

25

git patch

Author: Christoph, 2013-02-01

Source

2 answers

Intente cotejarlo con su archivo de parche-ejemplo:

git apply --reject mypatch.patch

Esto le mostrará las diferencias si las hay-aquí hay un ejemplo de cómo podría verse:

error: patch failed: <filename>:<linenumber>
error: while searching for :
    cout << "}" << endl; // example of a line in your patch

3

Author: serup,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-11-18 12:09:11

score 28 · Accepted Answer

Actualización:

Puede usar git apply -v para ver información más detallada sobre lo que está pasando, git apply --check para verificar la operación, o git apply --index para reconstruir el archivo de índice local.

Basado en su comentario, parece que su índice local estaba dañado, y entonces index lo resolvió.

Dejaré mi respuesta original y los comentarios principalmente para dar contexto a la gente sobre lo que estaba pasando, ya que sospecho que otras personas saltarían a las mismas conclusiones iniciales que yo había basado en el problema descripci.

------

Lo más probable es que no haya nada malo con la diferencia. En su lugar, mira el repositorio git de destino. Mientras estás haciendo git reset --hard HEAD, nada te garantiza que el HEAD en ese otro repositorio sea el mismo que el HEAD en tu.

Haga git log en el repositorio de destino y mire la confirmación en la parte superior. Es el mismo que el que produce la diferencia? Lo más probable es que no. Mira el historial y comprueba si el commit que necesitas está ahí. Si lo es, entonces el repositorio objetivo está por delante del tuyo, y tienes que volver, hacer git pull (o git rebase) y producir un nuevo diff. Si no lo es, entonces el repositorio objetivo está detrás del tuyo, y necesitas hacer git pull (o git rebase) en el repositorio objetivo para ponerlo al día.

Tenga en cuenta que si tiene otras personas que se comprometen a su repositorio "maestro" (el que el bot suyo y los repositorios de destino están tirando de), es posible que tenga que git pull ambos repositorios, para llegar a un común razonablemente reciente cometer.