tag - ¿Quién borró mi cambio en git?
git ver commits pendientes (4)
Si conoce alguna subcadena que estaría en la línea que se eliminó, entonces puede usar la opción -G para git log para encontrar confirmaciones que introdujeron un cambio que agregó o eliminó líneas que contenían esa subcadena. por ejemplo, si sabía que la palabra "pandemia" estaba en la línea que desapareció, puede hacerlo:
git log -Gpandemic -p
(El parámetro para -G puede ser una expresión regular). Esta opción se agregó recientemente a git. Si no funciona, intente con -S , que tiene una semántica ligeramente diferente, pero debería tener un efecto similar.
Este fue mi problema durante los últimos 30 minutos: tuve un par de cambios que desaparecieron en uno de mis archivos y no sé cuándo sucedió. ¡Y quiero saber quién hizo eso!
Comencé a buscar las revisiones con mis archivos:
git grep <searched_string> $(git rev-list --all) -- <file>
es la ruta al archivo o un comodín como * .gsp
Tengo un montón de revisiones, miro la última y trato de conseguir a sus hijos (pensando que el primer niño debería ser la primera revisión donde desaparecieron mis cambios)
git rev-list --children <revision_id>
Son los 40 caracteres desde el principio de la última línea del comando anterior.
¡Acercándose! Estoy mirando el comienzo de la salida, tomo el primer hijo y luego corro
git log <revision_id_s_first_child> --stat
Luego miro la salida y encuentro mi archivo y ¡quién hizo el cambio! (Resultó que yo tenía la culpa ...)
¿Hay alguna forma de hacerlo más rápido (la culpa de Git no mostraría lo que se ha eliminado)?
Tenga en cuenta que desde Git 2.11 (Q4 2016), no tendrá que especificar ..HEAD si desea ver las confirmaciones entre una específica y la actual .
Entonces la answer sería entonces:
git blame --reverse abcdef01 -- <file>
Ver commit d993ce1 (14 de junio de 2016) por Junio C Hamano ( gitster ) .
(Fusionada por Junio C Hamano - gitster - in commit 1172e16 , 10 oct 2016)
culpar: dwim "
blame --reverse OLD" como "blame --reverse OLD.."Es un error común decir "
git blame --reverse OLD path", esperando que la línea de comando se reduzca como si preguntara cómo las líneas en la ruta en una antigua revisión OLD han sobrevivido hasta la confirmación actual.En lugar de requerir siempre los dos extremos de un rango, podríamos DWIM "
OLD", que podría estar mal escrito "OLD..", para que sea un rango que termine en la confirmación actual.
git blame --reverse ahora incluye:
--reverse <rev>..<rev>:
Camina la historia hacia adelante en lugar de hacia atrás.
En lugar de mostrar la revisión en la que apareció una línea, muestra la última revisión en la que ha existido una línea.
Esto requiere un rango de revisión comoSTART..ENDdonde el camino a culpar existe enSTART.
git blame --reverse STARTse toma como elgit blame --reverse START..HEAD.
(Nota de la nota: "dwim" es un acrónimo de "Haz lo que quiero decir" (no lo que digo) )
git blame tiene una opción --reverse que toma un rango de confirmaciones y te muestra la última confirmación donde existía una línea antes de que se eliminara. Entonces, encuentra una confirmación que sabe que las líneas estaban allí, digamos abcdef01 por ejemplo, y para mostrar la última confirmación antes de la eliminación, haga:
git blame --reverse abcdef01..HEAD -- <file>
git blame --reverse puede acercarte a donde se borra la línea. Pero en realidad no apunta a la revisión donde se elimina la línea. Apunta a la última revisión donde estaba presente la línea. Luego, si la siguiente revisión es una confirmación simple , tiene suerte y obtuvo la revisión de eliminación. OTOH, si la siguiente revisión es una confirmación de fusión , entonces las cosas pueden ponerse un poco salvajes. Como parte del esfuerzo por crear una avería , abordé este mismo problema, por lo que si ya tiene Python instalado en su caja y está dispuesto a intentarlo, no espere más y hágame saber cómo va.