single - git patch unstaged

¿Cómo puedo hacer que git am/git aplique el trabajo "difuso" como el comando parche?

Question

He estado usando git-format-patch y git-am para aplicar los cambios de un repositorio a otro. Las estructuras de archivos son las mismas, pero hay algunos cambios en el repositorio a los que aplico, lo que hace que la mayoría de los parches falle en algunos tíos. Pero la mayoría de los trozos de parche se aplican con un poco de confusión en los números de línea.

Hasta donde puedo decir, git-am apply una interpretación muy estricta, por lo que rechaza todos estos parches.

Entonces mi flujo de trabajo se ha convertido

$ git am ../the-patch.patch
# Fails because the patch doesn''t apply cleanly
$ patch -p1 < ../the-patch.patch
# Applies most of the hunks, leaves .rej files for the ones that conflict
# Fix the conflicting hunks manually
$ git am --continue

Sería bueno si no tuviera que ejecutar el parche de la línea de comandos y eso podría ocurrir como parte del comando am.

Correr con la bandera --reject parece crear un archivo .rej con todos los trozos en el archivo si hay algún conflicto, que no es lo que quiero.

Ejecutar con la bandera --3way falla con

fatal: sha1 information is lacking or useless (the-file.java).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.

Lo que supongo es porque el conjunto de cambios en el que se basó no está en el repositorio en el que me estoy fusionando.

¿Hay alguna forma de hacer que git-am apply el parche con concordancia difusa como hace el comando de parche sin formato y solo crear archivos .rej que contienen los trozos que fallaron?

Answer 1

Basado en el hilo que @Nick Desaulniers vincula arriba, parece que usar la opción -3 para git apply / am funcionará, al menos hasta cierto punto.

Por ejemplo, aquí está mi salida con un parche que falló con git apply :

$ git apply < patch_file.patch error: patch failed: file_being_patched.txt:489 error: file_being_patched.txt: patch does not apply $ git apply -3 < patch_file.patch error: patch failed: file_being_patched.txt:489 Falling back to three-way merge... Applied patch to ''file_being_patched.txt'' cleanly.

Es una lástima que todavía ofrezca un error (más difícil de analizar la salida en las secuencias de comandos), y no dice cuál es el nivel de fuzz del modo en que lo hace, ya que el nivel de fuzz suele ser una buena indicación de si el comando de parche podría haberlo entendido mal

Answer 2

Esto tiene los ingredientes de una solicitud de función. Para estar seguro de eso, únase a la lista de correo de Git ([email protected]) y léala por un tiempo para tener una idea de la cultura. Al mismo tiempo, aclare sus ideas preparando la documentación anterior / posterior tal como se sugirió anteriormente.

Cuando se sienta preparado, preséntese en la lista y explíquele su idea de manera consecuente. Asegúrese de abordar la cuestión de si el efecto de su propuesta puede lograrse de manera adecuada por otros medios. Si recibe palabras de aliento, continúe con su documentación más detallada. Con los comentarios de su propuesta en la mano, puede decidir enviar un error de solicitud de función, o puede encontrarse en posición de crear un parche para su consideración.

Answer 3

Hay un parámetro --recount, pero solo para el comando git-apply, por lo que la secuencia teórica sería:

git mailsplit ...
git mailinfo ...
git apply --recount ...
git add ...
git commit ...

Answer 4

Si te entiendo correctamente, intentas combinar código de formulario 1 a otro y estás fallando en algunas partes de tu código. Luego lo arreglas manualmente y de ahora en adelante quieres que se fusione sin ningún error.

En este caso debes usar git rerere

En un flujo de trabajo que emplea ramas temáticas relativamente longevas, el desarrollador a veces necesita resolver los mismos conflictos una y otra vez hasta que las ramas del tema se hayan completado (ya sea fusionadas a la rama "release", o enviadas y aceptadas en upstream).

Este comando ayuda al desarrollador en este proceso al registrar los resultados automotrices en conflicto y los correspondientes resultados de resolución de mano en la fusión manual inicial, y aplicando resoluciones de mano grabadas previamente a sus correspondientes resultados automotrices.

git config --global rerere.enabled true