¿Qué hace "parche" con files ".rej" si hay muchos parches con rechazos?

Voy a aplicar aproximadamente 305 parches, y que habrá muchos "rechazos".

Antes de hacer esto, me gustaría saber qué patch hará si ya existe un file .rej , como espero que sea.

Mi alternativa es usar --merge , que crea las tags <<<...>>> que son tan familiares para los usuarios de git . (Heh …) Pero en este caso, me temo que la presencia de esas tags, si hubiera muchas, podría interferir con el futuro parchado.

(¿Alguna opinión sobre cuál podría ser mejor?)

Básicamente, tengo la intención de "aplicar los parches, en un bucle for , dejarlos hacer lo mejor que puedan, y luego limpiar". (Promete ser una tarde encantadora.) Sé que haré este paso muy manualmente y todavía no sé cuántos files .rej podría haber. (Ya puedo ver que habrá más de 100, sin embargo).

Historias de guerra bienvenidos.

patch simplemente sobrescribe el file .rej existente. Pero puede enviar rechazos al file de su elección usando la opción -r :

-r Rejectfile o --reject-file= rejectfile

Coloque los rechazos en el file de rechazo en lugar del file .rej pnetworkingeterminado. Cuando rejectfile es - , descartar rechazos.

Tenga en count que en este caso los trozos rechazados para diferentes files se ponen todos en el mismo file en formatting de diff unificado.

Por lo tanto, puede escribir su ciclo para usar un file de rechazo diferente en cada iteración:

 for p in patch* do patch -p0 -r "$p".rej <"$p" done 

Sin embargo, mi consejo es detener el process de parche tan pronto como se rechace un solo bloque y resolver el conflicto antes de continuar. Puede codificar esa lógica en su bucle de parchado similar a la siguiente:

apply_patches

 #!/bin/bash for p in "$@" do echo echo "----------- Applying patch $p ------------" rejectfile="$p".rej patch -p0 -r "$rejectfile" <"$p" if [ -s "$rejectfile" ] then echo echo "Some hunks could not be applied (see $rejectfile)" read -p "Please address them and then press ENTER " fi done 

Para documentar ahora cómo resultó este esfuerzo:

Sí, el patch sobrescribe los files .rej , y el guión sugerido de Leon fue mi muy buen punto de partida. Sin embargo, descubrí que el contenido del file .rej era esencialmente inútil para mí. Volviendo a leer la documentation del patch (en Linux , pero no (!) En Macintosh OS / X!), Vi que había una opción --merge disponible que produciría el <<<< ==== >>>> modificaciones en el file (como git rutinariamente …)

Utilicé el command git format-patch para get la list de confirmaciones como files de parches individuales, y modifiqué el script original de Leon para recorrer el contenido de ese directory.

En lugar de usar la opción -r , como sugirió Leon, utilicé la opción --merge . Como ahora no habría ningún file de rechazo para probar, cambié el script para usar el código de salida ( "$?" ) Del command de patch , en su lugar. (Como siempre, "cero es igual a éxito")

Si el command de patch tuvo éxito (regresó a cero …), mi script convertiría el file de parche en otro directory de "parches aplicados". Si no, imprimiría un post y se detendría. Resolví cada uno de estos casos de la siguiente manera:

  • Uno por uno, observe cuál de los files en el parche tenía errores. Abra cada uno de estos files y busque la label <<<<< . De esta forma pude ver las dos alternativas una al lado de la otra y, caso por caso, hice una elección individual y una corrección manual.

  • Luego, mv el file de parche en el directory "parches aplicados", tal como lo hubiera hecho el script si el parche se hubiera aplicado por completo sin error.

  • Escanee el directory fuente (PHP …) para detectar cualquier error de syntax, usando una herramienta personalizada de mi layout. Inmediatamente (!) Resuelva cualquier problema encontrado.

  • git commit los cambios … ¡por las dudas!

  • Comience el script de nuevo …

Y ahora, un problema interesante. . .

Ahora, como dije en la publicación original, estaba aplicando estos (cientos de …) parches en una base de código fuente que se había copydo textualmente durante muchos meses. (En el momento de la split, un repository de git ni siquiera existía. La compañía todavía estaba usando SVN.) Por lo tanto, casi nunca se podía usar patch en los numbers de línea.

En todos los casos, el patch pensó que había encontrado el lugar correcto para aplicar cada parche, en algún "desplazamiento" desde el número de línea que figura en el parche. Sin embargo, encontré en algunos casos que el patch no había (!) Identificado correctamente todo. A veces, marcaba una "inserción" frente a una pieza idéntica de código existente, donde un ser humano reconocería que no era una inserción en absoluto.

Estoy, por supuesto, en este momento "esperando ansiosamente" que en cada caso el patch haya "reconocido su propia incertidumbre" y, por lo tanto, ninguno de los parches "aplicados con éxito" (aproximadamente dos tercios de ellos, como se ve después). ..) probará tener problemas de duplicación. (Esta es una de las principales razones por las que constantemente verificamos los errores de syntax en cualquier parte de la base de códigos, y, como ocurre, casi nunca encontramos ninguno).