patch - stash - git stage

git add--interactive "Tu pedazo editado no se aplica" (10)

Estoy tratando de usar git add --interactive para agregar selectivamente algunos cambios a mi índice, pero continuamente recibo el mensaje "Su trozo editado no se aplica. Edite nuevamente ...". Recibo este mensaje incluso si elijo la opción ey guardo / cierro mi editor de inmediato. En otras palabras, sin editar el trozo, el parche no se aplica.

Aquí está el ejemplo exacto que estoy usando (estoy tratando de armar una pequeña demostración):

Archivo original:

first change second change off branch third change off branch second change third change fourth change

Archivo nuevo:

Change supporting feature 1 first change second change off branch third change off branch second change third change fourth change bug fix 1 change supporting feature 1

Estoy tratando de mostrar cómo usar git add --interactive para agregar solo la línea "corrección de errores 1" al índice. Al ejecutar el complemento interactivo en el archivo, elijo el modo de parche. Me presenta con

diff --git a/newfile b/newfile index 6d501a3..8b81ae9 100644 --- a/newfile +++ b/newfile @@ -1,6 +1,9 @@ +Change supporting feature 1 first change second change off branch third change off branch second change third change fourth change +bug fix 1 +change supporting feature 1

Respondo con división, seguido de "no" para aplicar el primer trozo. El segundo galán, trato de editar. Intenté originalmente eliminar el resultado final, eso no funcionó. Dejar el trozo solo por completo tampoco funciona, y no puedo entender por qué.

¿Esto es como en esta publicación de git-add ?

Editar manualmente el trozo es inmensamente poderoso, pero también un poco complicado si nunca lo has hecho antes.
Lo más importante a tener en cuenta: La diferencia siempre se sangra con un carácter, además de cualquier otra sangría que exista.
El personaje puede ser:
un espacio (indica una línea sin cambios),
a - indicando que la línea fue removida,
o a + que indica que se agregó la línea.
Nada más. Debe ser un espacio, un - o un +. Cualquier otra cosa, y obtendrás errores
(No hay caracteres para una línea modificada, ya que se manejan eliminando la línea anterior y añadiendo la nueva como nueva).
Como tiene el diff abierto en su editor de texto favorito (configuró Git para usar su editor de texto favorito, ¿no?), Puede hacer lo que quiera, siempre y cuando se asegure de que la diferencia resultante se aplique limpiamente.
Y ahí radica el truco. Si nunca has hecho esto antes, Git te dirá "Tu pedazo editado no se aplica. ¿Editar nuevamente?" muy a menudo, comenzará a odiarse a sí mismo por su incapacidad para resolver esto , a pesar de que parece tan fácil (o Git porque no puede entender lo que quiere).
Una cosa que me hizo tropezar con bastante frecuencia fue que olvidé la sangría de un carácter.
Marcaría una línea con un - para ser eliminado, pero en la mayoría de los editores de texto que inserta un - , no sobrescribe el espacio que estaba allí antes. Esto significa que está agregando un espacio adicional a toda la línea, lo que a su vez significa que el algoritmo diff no puede encontrar / unir la línea en el archivo original, lo que a su vez significa que Git le gritará .
La otra cosa es que la diferencia todavía tiene que tener sentido. "Sentido" significa que se puede aplicar limpiamente. Exactamente cómo se crea un diff sensible parece ser un poco oscuro (al menos para mí en este momento), pero siempre debes tener en cuenta cómo era el archivo original, y luego planificar tus -s y + s en consecuencia. Si editas tus trozos con la suficiente frecuencia, eventualmente conseguirás el truco.

Ver también este commit en git add -p .

Cuando no desee eliminar una línea que haya sido eliminada, como en

first line -second line third line

donde desee mantener la segunda línea, asegúrese de reemplazarla por un espacio, en lugar de eliminar toda la línea (como lo haría para deshacerse de una línea adicional). Git usará la línea para el contexto.

Hace poco descubrí leyendo este hilo cómo trabajar la edición manual.

El truco que utilicé fue que si tengo una diferencia como esta.

+ Line to add + Line to add + Line I dont want to include + Line I dont want to include

El truco es eliminar las dos líneas que no quiero completamente haciendo que el diff resultante se vea así.

+ Line to add + Line to add

Si bien esto es muy obvio para la mayoría de las personas, no fue para mí hasta hoy y pensé que debería compartir mi experiencia. Por favor, dime si hay algún peligro para este método.

Llegué a esta pregunta buscando la solución al mismo problema, y no pude encontrar la forma de cambiar los números de línea (como se sugirió anteriormente) en el trozo para que git lo acepte en mi caso. Sin embargo, encontré una manera mucho mejor de hacerlo usando git gui . Allí puede seleccionar las líneas en la diferencia que desea representar, luego haga clic con el botón derecho y seleccione "Líneas de escenario desde la confirmación". Recuerdo que git-cola tiene la misma funcionalidad.

Para este ejemplo en particular, necesita ajustar los números de línea en el trozo. Cambiar la línea:

@@ -1,6 +2,8 @@

para que en cambio lea:

@@ -2,7 +2,8 @@

Por supuesto que llegué tarde a esto, pero quería mencionar para el registro que este tema fue discutido el año pasado en la lista de correo git y parece que desde entonces no ha cambiado mucho.

Este problema particular se deriva de la división y el intento de editar el mismo trozo. El análisis, tal como fue publicado originalmente por Jeff King, del problema subyacente es esencialmente:

Hm. OK veo. La comprobación "does this diff apply" alimenta ambas partes del parche dividido a git-apply. Pero, por supuesto, la segunda parte nunca se aplicará correctamente, porque su contexto se solapa con la primera parte, pero no la tiene en cuenta.
Hacer el chequeo solo con el parche editado funcionaría. Pero eso no tiene en cuenta que su parche editado no se aplicará en el largo plazo, dependiendo de si acepta o no la otra mitad del parche dividido. Y todavía no podemos saberlo, porque es posible que el usuario no nos lo haya dicho (podrían haber salteado la primera mitad y luego volver a ella más tarde después del paso de edición).

Jeff concluye su publicación con una solución muy pragmática que siempre tiene éxito y, por lo tanto, es muy recomendable:

Entonces, en general, creo que dividir y editar el mismo trozo es intrínsecamente peligroso y conducirá a este tipo de problemas. Y debido a que la edición proporciona un superconjunto de la funcionalidad, creo que debería simplemente editar y permitir que la primera parte del trozo se aplique o no según sus preferencias.

Al elegir editar un trozo que no se haya dividido previamente, no tendrá que ocuparse de los números de línea.

Puede editar manualmente los números de línea, eso es definitivamente útil en algunos casos. Sin embargo, probablemente podría haber evitado este problema en particular al NO dividir primero el trozo.

Si ve que probablemente necesite editar algo más tarde en el trozo que Git ha elegido automáticamente, es mejor simplemente editar todo el trozo en lugar de dividir, organizar la mitad, y luego editar la otra mitad. Git hará un mejor trabajo averiguándolo.

También es importante modificar correctamente el encabezado del trozo (por ejemplo, @@ -1,6 +1,9 @@ ). Joaquín Windmuller revela el secreto de la edición de encabezados hunk en una de sus publicaciones de blog .

Los secretos de la edición hunks
La edición de los temas puede ser confusa al principio, las instrucciones que git te da ayuda pero no son suficientes para comenzar.
# —|| # To remove ‘-’ lines, make them ’ ’ lines (context). # To remove ‘+’ lines, delete them. # Lines starting with # will be removed. # # If the patch applies cleanly, the edited hunk will immediately be # marked for staging. If it does not apply cleanly, you will be given # an opportunity to edit again. If all lines of the hunk are removed, # then the edit is aborted and the hunk is left unchanged.
La salsa secreta es ... contar líneas:
Si elimina una línea que comienza con +, resta uno al nuevo recuento de líneas (último dígito del encabezado del trozo) .
Si elimina una línea que comienza con - luego agregue uno al recuento de la nueva línea (último dígito del encabezado del trozo) .
No elimine las otras líneas (líneas de referencia).
Esto debería permitirle modificar rápidamente las partes para seleccionar las partes que desea.

Un problema adicional que tuve cuando recibí este error fue que las terminaciones de línea cambiaron cuando guardé el archivo de edición.

Estaba usando Windows y usando el Bloc de notas para mis ediciones (solo se guarda con los finales de línea de Windows). Mi código fue escrito con Notepad ++ y lo configuré para tener terminaciones de línea de estilo Unix / Linux.

Cuando cambié mi configuración para tener Notepad ++ como el editor predeterminado de git, pude hacer mis ediciones al experto.

git config --global core.editor "notepad++"

Una razón para los mensajes extraños "Tu trozo editado no se aplica" (probablemente acompañado con algo así como "error: fragmento de parche sin encabezado en la línea ...") podría ser tu editor si está configurado para quitar espacio en blanco al final. Obviamente, esto causaría grandes problemas ya que los parches codifican líneas vacías ya que las líneas con un espacio que cualquier trozo que contenga líneas vacías no se aplicarán si se guardan con dicho editor. Así que, en efecto, cualquier trozo que contenga líneas vacías sin modificar no se aplicará después de la edición con si está activado el espacio en blanco de arrastre.