oneline - git log--format
¿Por qué git log--cherry-pick no elimina las confirmaciones equivalentes? (2)
A menudo me pregunto si git siempre debería comprobar ambos, pero eso es probablemente un éxito de rendimiento considerable.
Ese comportamiento es ahora (Git 2.11, Q4 2016) más rápido que antes.
Consulte commit 7c81040 (12 de septiembre de 2016) y commit 5a29cbc (09 de septiembre de 2016) por Jeff King ( peff
) .
Ayudado por: Johannes Schindelin ( dscho
) .
(Fusionada por Junio C Hamano - gitster
- in commit f0a84de , 21 de septiembre de 2016)
patch-ids
: se niegan a computarpatch-id
para la combinación de combinaciones"
git log --cherry-pick
" solía incluir combinaciones de combinaciones como candidatos para que se comparen con otras confirmaciones, lo quegit log --cherry-pick
una gran cantidad de tiempo perdido. La lógica de generación del parche-id se ha actualizado para ignorar las fusiones para evitar el desperdicio.[...] podemos pasar mucho tiempo extra computando estas diferencias de fusión.
En el caso que inspiró este parche, un "git format-patch --cherry-pick
" cayó de más de 3 minutos a menos de 3 segundos.
He estado tratando de usar
git log --no-merges --cherry-pick --right-only master...my-branch
para generar una lista de confirmaciones que están en my-branch, pero no en master (según la documentación de git-log). Sin embargo, todavía hay muchas confirmaciones equivalentes que están apareciendo en la lista. Si les muestro a ellos y sus parches, no hay diferencia aparte del ID de confirmación.
git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 >patcha
git show c53c7c32dcd84bfa7096a50b27738458e84536d5 >patchb
diff patcha patchb
1c1
< commit 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621
---
> commit c53c7c32dcd84bfa7096a50b27738458e84536d5
E incluso git patch-id
muestra como equivalentes:
git show c53c7c32dcd84bfa7096a50b27738458e84536d5 | git patch-id
2b5504fb9a8622b4326195d88c7a20f29701e62b c53c7c32dcd84bfa7096a50b27738458e84536d5
git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 | git patch-id
2b5504fb9a8622b4326195d88c7a20f29701e62b 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621
¿Cómo git log --cherry-pick
no recoge estos como duplicados?
¿Te has fusionado maestro en tu rama desde que hiciste las selecciones de cereza? --cherry-pick
funciona primero haciendo coincidir el ID de confirmación, y luego, si eso falla, busca el ID de parche. Si ha fusionado el maestro en su rama, ahora tendrá el compromiso real en su rama y la versión seleccionada. Por lo tanto, encontrará el ID de confirmación y luego procederá a informar la versión seleccionada.
A menudo me pregunto si git siempre debería comprobar ambos, pero eso es probablemente un éxito de rendimiento considerable.