¿Por qué `git stash-p` a veces falla?
I ♥ git stash -p. Pero a veces, después de una sesión satisfactoria de y, n, y s, entiendo esto:
Saved working directory and index state WIP on foo: 9794c1a lorum ipsum
error: patch failed: spec/models/thing_spec.rb:65
error: spec/models/thing_spec.rb: patch does not apply
Cannot remove worktree changes
¿Por qué?
5 answers
git stash -p debería fallar menos con Git 2.17 (Q2 2018).
Antes de eso," git add -p "(que comparte lógica con git stash) ha sido perezoso en fusionar parches divididos antes de pasar el resultado a" git apply " subyacente, lo que lleva a errores de mayúsculas y minúsculas; la lógica para preparar el parche que se aplicará después de las selecciones de hunk se ha ajustado.
Véase commit 3a8522f, commit b3e0fcf, commit 2b8ea7f (05 Mar 2018), commit fecc6f3, commit 23fea4c , commit 902f414 (01 Mar 2018), y commit 11489a6, commit e4d671c, commit 492e60c (19 Feb 2018) por Phillip Wood (phillipwood).
(Merged by Junio C Hamano -- gitster -- in commit 436d18f , 14 Mar 2018)
add -p: ajustar las compensaciones de trozos posteriores cuando se omite uno
(añadir, pero de nuevo, se puede aplicar al alijo)
Desde que commit 8cbd431 ("
git-add--interactive: reemplazar hunk recounting with apply rec recount", 2008-7-2, Git v1.6.0-rc0) si se omite un trozo, entonces dependemos de las líneas de contexto para aplicar trozos posteriores en la derecha lugar.Si bien esto funciona la mayor parte del tiempo, es posible que los tíos guapos terminan siendo aplicados en el lugar equivocado.
Para arreglar esto, ajuste el desplazamiento de trozos posteriores para corregir cualquier cambio en el número de inserciones o eliminaciones debido al trozo omitido. El cambio en la compensación debido a trozos editados que tienen el número de inserciones o eliminaciones cambiado se ignora aquí, se arreglará en la próxima confirmación.
Puedes ver algunas pruebas aquí.
Git 2.19 mejora git add -p: cuando el usuario edita el parche en "git add -p" y el editor del usuario está configurado para eliminar los espacios en blanco finales indiscriminadamente, una línea vacía que no se modifica en el parche se volvería completamente vacía (en lugar de una línea con un único SP en ella).
El código introducido en Git 2.17 timeframe no pudo analizar dicho parche, pero ahora aprendió a notar la situación y hacer frente a ella.
Véase commit f4d35a6 (11 de junio de 2018) por Phillip Wood (phillipwood).
(Merged by Junio C Hamano -- gitster -- in commit 5eb8da8, 28 Jun 2018)
add -p: se corrige el conteo de líneas de contexto vacías en parches editados
recount_edited_hunk()introducido en commit 2b8ea7f ("add-p: calcular el desplazamiento delta for edited patches", 2018-03-05, Git v2.17.0) requiere que todas las líneas de contexto comiencen con un espacio, las líneas vacías no se cuentan.
Esto tenía la intención de evitar cualquier problema de recuento si el usuario había introducido líneas vacías al final al editar el parche.Sin embargo, esto introdujo una regresión en '
git add -p', ya que parece que es común que los editores eliminen el espacio en blanco final de las líneas de contexto vacías cuando se editan parches, lo que introduce líneas vacías que deberían ser contar.
'git apply' sabe cómo tratar con estas líneas vacías y POSIX afirma que si hay o no un espacio en una línea de contexto vacía está definida por la implementación (ver diff command).Arregla la regresión contando líneas que consisten únicamente en una nueva línea así como las líneas que comienzan con un espacio como líneas de contexto y agregar una prueba para prevenir futuras regresiones.
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
2018-08-27 07:08:17
Esto me sucede cada vez que intento dividir un trozo en trozos más pequeños que están demasiado juntos (menos de 3 líneas entre cambios). La breve explicación es que el parche tiene líneas de contexto que entran en conflicto con los cambios locales. Explicación más completa a continuación.
Supongamos que tengo un repositorio git con estos cambios sin confirmar:
--- a/pangram
+++ b/pangram
@@ -1,8 +1,8 @@
The
-quick
+relatively quick
brown
fox
-jumps
+walks
over
the
lazy
Si guardo el primer cambio, obtengo:
--- a/pangram
+++ b/pangram
@@ -1,5 +1,5 @@
The
-quick
+relatively quick
brown
fox
jumps
El comando git stash realmente tiene éxito en guardar el parche (comprobar git stash list), pero luego git usa ese parche al revés para eliminar los cambios guardados de mi directorio de trabajo. El contexto después de que el pedazo tiene "saltos", que no coincide con los" paseos " todavía en mi dir de trabajo. Así que git rescata con
error: patch failed: pangram:1 error: pangram: patch does not apply Cannot remove worktree changes
Y deja todos los cambios en mi dir de trabajo, y el alijo se vuelve prácticamente inútil.
Yo llamaría a esto un error en el soporte de división de trozos de git. Si sabe que está dividiendo los cambios demasiado cerca, podría recortar algunas líneas de contexto de el parche, o jimmy el parche para tener las líneas de contexto modificadas en lugar de las prístinas. Alternativamente, si dividir trozos de este cierre no es compatible oficialmente, en realidad debería negarse a dividir trozos de ese cierre.
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
2012-10-06 21:08:57
Después de tener un error git stash -p de la misma manera, tuve suerte con esta solución (git 2.0.2):
-
git add -p, dividiendo exactamente los mismos trozos pero con respuestas inversas ("y" aadd"mantiene" los cambios, "n" astashmantiene los cambios.) -
git stash -kpara mantener el índice y guardar todo lo demás -
git resetpara seguir trabajando en mis archivos
No estoy seguro de por qué git add -p no falló de la misma manera que git stash -p. Supongo que porque agregar funciona con el índice en lugar de ¿creando un archivo de parche?
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
2017-03-30 01:20:19
Desafortunadamente, la respuesta aceptada en este momento puede fallar, incluso en Git 2.17.
Si, como yo, gastaste mucho esfuerzo en construir el alijo perfecto y no quieres desperdiciar ese esfuerzo, todavía es posible obtener principalmente lo que quieres con:
git stash show -p | patch -p1 -R
Esto fallará con rechazos, pero las probabilidades son buenas la mayoría de los trozos se aplicarán correctamente y al menos le ahorrará el tiempo de revisar todos los archivos de nuevo.
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
2018-04-07 20:46:34
Aplicar el estado puede fallar con conflictos; en este caso, no se elimina de la lista de alijos. Necesitas resolver los conflictos a mano y llamar a git stash drop manualmente después
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
2011-07-21 23:16:24