Duplicación de Git Merge después de un uso ineficaz de BFG

De alguna manera, me he vuelto loco por todo el repository (usado solo por mí) y podría necesitar ayuda para resolverlo.

Aquí esta lo que hice. Me di count de que en mi historial de confirmaciones, había algunos files que contenían cnetworkingenciales que no quería poner por ahí. Por lo tanto, decidí ser legítimo y tratar de utilizar el BFG Repo-Cleaner para solucionar estos problemas. Lancé todas las cnetworkingenciales en .gitignores, y seguí intentando borrarlos de la historia. De acuerdo con las instrucciones de documentation, ejecuté estos commands:

git clone --mirror myrepo.git java -jar bfg.jar --delete-files stuffthatshouldbedeleted.txt myrepo.git 

En este punto, BFG me dijo que se habían encontrado y eliminado x número de files. Dulce.

 cd myrepo.git git reflog expire --expire=now --all git gc --prune=now --aggressive git push 

De acuerdo con los loggings del terminal, se actualizó el repository. Hasta aquí todo bien, ¿no? Ingreso en mi count de github y, luego de unos pocos clics, encuentro las cnetworkingenciales que todavía están allí, el file y todo, en mi historial. Vuelvo y pruebo el mismo set de commands, pero usando esta línea en lugar del eliminador de files:

 java -jar bfg.jar --replace-text passwords.txt myrepo.git 

donde passwords.txt es un file que contiene instancias de cadena de todas las cnetworkingenciales a las que me gustaría haber ido. Una vez más, los loggings de BFG indican que hay varias instancias que ha corregido. Empujo hacia arriba, compruebo, y las cnetworkingenciales siguen allí, sentado en Github. Noté que las teclas SHA-1 para todas mis confirmaciones han sido alteradas, así que presumiblemente BFG hizo algo, simplemente no es lo que quiero que haga.

En este punto, me rindo y trato de volver al trabajo, imagino que lo resolveré más tarde. Hago algo de trabajo, trato de upload de presión, get un conflicto de fusión extraño (tienes 50 delante y 50 detrás en los commits). ¿Qué? Intento tirar y fusionar, y de repente, cada compromiso en mi historial de git se duplica en nombre, y algunos de ellos simplemente están en blanco. Compruebo mi gráfico de networking de Github, y parece que hay una segunda twig a partir de mi confirmación inicial que refleja exactamente todas mis confirmaciones que se han cerrado con mi último compromiso (nunca he ramificado, simplemente he estado avanzando linealmente).

No puedo volver a una confirmación anterior porque están duplicates cronológicamente. Mis cnetworkingenciales todavía están ahí, con el doble de instancias ahora, y mi historial se duplica y es muy confuso para tratar de comprender. Cuando bash ejecutar BFG desde el principio ahora, clonando y duplicando el repository de nuevo, me dice que no hay cnetworkingenciales, a pesar de que puedo verlas en Github. Realmente podría usar algo de ayuda para entender lo que sucedió, y cómo, si es que lo hago, puedo volver a un estado de cosas nuevamente.

Estoy considerando simplemente eliminar todo el repository y comenzar de nuevo. Realmente no quiero hacer eso.

tldr; Intenté usar BFG, de alguna manera dupliqué versiones medio cocidas de todos los commits en mi repository, no puedo desennetworkingarme, y para colmo de males, BFG no hizo nada y afirma que ha hecho su trabajo.

Soy el autor de BFG. Intentaré describir lo que creo que ocurrió paso a paso en function de su count:

La limpieza manual previa al BFG …

Primero tú:

arrojó todas las cnetworkingenciales en .gitignores, y pasó a tratar de borrarlos de la historia.

Esta descripción de sus acciones omite dos pasos esenciales:

  1. Eliminar manualmente las cnetworkingenciales de su tree de files actual y confirmar ese cambio en su repository. Si no hiciste esto, el BFG habría erradicado el contenido de tus commits anteriores, pero ha protegido la suciedad en tus commits actuales . Este comportamiento se trata en la documentation de BFG en la sección titulada " Sus files actuales son sagrados … ", y si se olvida de hacerlo, el BFG imprime un post de advertencia cuando lo ejecuta (" ADVERTENCIA: el contenido sucio anterior puede ser eliminado de otras confirmaciones, pero como las confirmaciones protegidas aún lo usan, TODAVÍA existirá en su repository … "etc., etc.). ¿Viste ese post cuando ejecutó el BFG?

  2. Ese compromiso debe ser enviado a su repository de GitHub antes de clonar el espejo completo de su repository. ¿Olvidaste ese paso?

Si no hizo esas cosas, eso explicaría que sus cnetworkingnentials no se borren por completo de su repository.

Ejecutando BFG por primera vez …

Continuando, entonces usted:

  • hizo un clon de espejo nuevo de su repository de GitHub
  • ejecutó el BFG, filtrando usando la opción --delete-files (¿vio una advertencia de contenido protegido?)
  • empujó el repository actualizado a GitHub

…en cuyo punto :

De acuerdo con los loggings del terminal, se actualizó el repository. Hasta aquí todo bien, ¿no? Salgo a mi count de github y, después de unos pocos clics, encuentro las cnetworkingenciales que todavía están allí, el file y todo, en mi historial

Entonces, suponiendo que eliminaste manualmente tu contenido incorrecto de tus últimas confirmaciones antes de ejecutar el BFG, lo que viste es bastante extraño. Algunas causas posibles:

a) El repository no se clonó con la bandera --mirror , por lo que no se sobrescribieron todas las twigs en GitHub, dejando un historial sucio en las twigs no maestras. Sin embargo, ha declarado explícitamente que utilizó el indicador --mirror .

b) Incluso con un push de espejo en GitHub, las confirmaciones antiguas siguen estando disponibles allí cuando se hace reference por commit-id explícito (es decir, una url GitHub que tiene la identificación de compromiso), hasta que el punto GitHub ejecuta su recolección automática de basura en tu repository Las requestes de extracción y las bifurcaciones también pueden conservar confirmaciones del historial anterior. Esa sería otra posible explicación para los commits sucios que viste.

Ejecutando BFG por segunda vez …

En cualquier caso, en ese punto usted estaba preocupado, y:

  • ejecuté el BFG nuevamente, esta vez con --replace-text passwords.txt , que actualiza el contenido del file en lugar de eliminar todo el file.

Una vez más, los loggings de BFG indican que hay varias instancias que ha corregido. Empujo hacia arriba, compruebo, y las cnetworkingenciales siguen allí, sentado en Github.

Es un poco curioso que el BFG dijera que había más contenido para limpiar, posiblemente sus cnetworkingenciales estuvieran en más lugares de los que pensaba, pero en cualquier caso, cualquiera que sea la causa para que los vea aún después de la primera carrera, es el la misma razón por la que los viste después de la segunda carrera.

Volviendo al trabajo

En este punto, me rindo y trato de volver al trabajo, imagino que lo resolveré más tarde.

Entonces, en este punto, has reescrito tu historial de repositorys de Git (¡dos veces!) Y lo has enviado a GitHub. Pero su count no menciona que borre todas sus copys antiguas locales del repository, como se especifica en las instrucciones de BFG:

"En este punto, estás listo para que todos puedan deshacerse de sus viejas copys del repository y hacer nuevos clones de los nuevos datos prístinos".

Entonces, ¿eliminaste tu antigua copy de trabajo del repository de Git en tu máquina de trabajo y volviste a clonar con el nuevo historial del repository de Git? La historia en su repository anterior habría sido diferente a la historia "limpiada" que habría estado presente en GitHub en ese momento (¡incluso si el historial 'limpiado' no hubiera sido 'limpiado' como le hubiera gustado!).

Hago algo de trabajo, trato de upload de presión, get un conflicto de fusión extraño (tienes 50 delante y 50 detrás en los commit).

Si estuvieras haciendo el trabajo en una vieja copy local de tu repository de Git (en lugar de una nueva clonación nueva de GitHub), entonces esto es lo que verías. Básicamente estás empujando 50 commits de historial viejo y sucio a GitHub, y para Git pareces felizmente inconsciente de que hay 50 completamente diferentes (para Git, que solo se preocupa solo de los commit-ids aquí) se compromete ya en esa twig. Git piensa que lo que estás haciendo es un poco raro ('50 por delante y 50 por detrás ') y está intentando decírtelo.

Empeorando las cosas …

¿Qué? Intento tirar y fusionar, y de repente, cada compromiso en mi historial de git se duplica en nombre, y algunos de ellos simplemente están en blanco. Compruebo mi gráfico de networking de Github, y parece que hay una segunda twig a partir de mi confirmación inicial que refleja exactamente todas mis confirmaciones con mi último compromiso.

Entonces, al hacer el pull y merge, has unido la historia limpia y la historia sucia, unificándolos con un commit de fusión. En términos de sorting de su historia, esta es una mala idea. Una mejor idea habría sido volver a establecer la base de tu nuevo trabajo sobre el historial limpio, presionarlo, eliminar tu anterior repository de trabajo y hacer un nuevo clon.

Las consecuencias

Cuando bash ejecutar BFG desde el principio ahora, clonando y duplicando el repository de nuevo, me dice que no hay cnetworkingenciales, a pesar de que puedo verlas en Github.

Esto es bastante extraño, pero en realidad no tengo ninguna explicación para eso aparte del error del operador, más allá de la explicación 'GitHub gc' ya mencionada anteriormente. Puede compartir el repository conmigo (si lo desea) para poder realizar una inspección más detallada, o simplemente enviarme una copy comprimida del directory '.bfg-report' para que pueda ver qué diagnósticos capturó el BFG en su ejecución.

Recuperación

Realmente podría usar algo de ayuda para entender lo que sucedió, y cómo, si es que lo hago, puedo volver a un estado de cosas nuevamente.

Espero haber logrado explicar algo de lo que sucedió.

En términos de orderar su historial (es decir, deshacerse de estos dos filamentos duplicates), debe restablecer su historial de Git al punto (limpiado) antes de agregar esa confirmación de fusión. Mire la confirmación de fusión e identifique qué historial de padres prefiere. ¿Cuál es la última confirmación ( xxxx ) en esa historia antes de realizar la fusión?

 git reset --hard master xxxx 

Esto bien puede perder el último trabajo que hiciste en tu viejo y sucio historial. Identifique ese compromiso ( yyyy ), y vuelva a basarlo en la parte superior de su historial, o simplemente guárdelo:

 git cherry-pick yyyy 

Finalmente, lleve su historial recuperado a GitHub con la bandera 'force':

 git push origin master -f 

… comprima un file de su repository anterior y luego elimine todas las copys locales antiguas de su repository para evitar más confusión. Haz un clon nuevo