git lfs bfg: después de eso, resolver conflictos ¿cómo?

Tenemos un repository en el cual cometimos instantáneas en PDF de los informes. Quiero probar git lfs, ver si mejora la calidad de vida.

Seguí los procedimientos aquí ( https://github.com/rtyley/bfg-repo-cleaner/releases ) para usar BFG para limpiar los binarys antiguos y hacer la transición a lfs. Me abrí paso a través de un par de arrugas relacionadas con el uso del server Gitlab para el repository, pero al final creo que todo salió bien.

Estoy escribiendo para mostrar lo que hicimos y hacer una pregunta sobre la limpieza de los conflictos de fusión al final.

Te mostraré la transcripción. Comprobamos un clon "- mirror" (un repository desnudo) y BFG hace su trabajo sobre eso, luego lo empujamos hacia atrás después de tocar el violín:

guides-to-lfs$ git clone --mirror git@gitlab.kucenter.edu:crmda/guides.git Cloning into bare repository 'guides.git'... X11 forwarding request failed on channel 0 remote: Counting objects: 865, done. remote: Compressing objects: 100% (527/527), done. remote: Total 865 (delta 318), reused 834 (delta 303) Receiving objects: 100% (865/865), 151.75 MiB | 25.74 MiB/s, done. Resolving deltas: 100% (318/318), done. Checking connectivity... done. guides-to-lfs$ cd guides.git/ guides.git$ java -jar ~/bin/bfg-1.12.13.jar --convert-to-git-lfs '*.{pdf,ogv,tar.gz,zip}' --no-blob-protection Using repo : /home/pauljohn/GIT/CRMDA/guides-to-lfs/guides.git Found 0 objects to protect Found 3 commit-pointing refs : HEAD, refs/heads/master, refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head Protected commits ----------------- You're not protecting any commits, which means the BFG will modify the contents of even *current* commits. This isn't recommended - ideally, if your current commits are dirty, you should fix up your working copy and commit that, check that your build still works, and only then run the BFG to clean up your history. Cleaning -------- Found 124 commits Cleaning commits: 100% (124/124) Cleaning commits completed in 1,933 ms. Updating 2 Refs --------------- Ref Before After -------------------------------------------------------------------- refs/heads/master | e3327ef1 | e4ac76a2 refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head | 74ccc454 | 6639b246 Updating references: 100% (2/2) ...Ref update completed in 19 ms. Commit Tree-Dirt History ------------------------ Earliest Latest | | .......DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD D = dirty commits (file tree fixed) m = modified commits (commit message or parents changed) . = clean commits (no changes to file tree) Before After ------------------------------------------- First modified commit | cdd8f486 | 5e6b64eb Last dirty commit | e3327ef1 | e4ac76a2 Changed files ------------- Filename Before & After -------------------------------------------------------------------------------------------------------------------- 01.LISREL.Syntax.pdf | 71a17dcc ⇒ 7f217f4d 02.ReadingDataIntoLISREL.pdf | c05c3fe6 ⇒ e7238e11 03.InterpretingLISRELOutput.pdf | 6ef054c8 ⇒ a2a63813 04.StartingValuesInLISREL.pdf | 335d7a09 ⇒ c86439ee, 9f6fc232 ⇒ 05182a86 05.WhatToReport.pdf | 2bee7a8d ⇒ 1106d2f4, 3d30b103 ⇒ ce27382c 06.Satorra-BentlerChi-Sq.pdf | 94ec6fd2 ⇒ b81d08b4, 7cd29d48 ⇒ 704d5f30 ... In total, 375 object ids were changed. Full details are logged here: guides.git.bfg-report/2016-10-05/14-03-18 BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive guides.git$ git reflog expire --expire=now --all guides.git$ git gc --prune=now 

En caso de que intente esto, debe estar listo para algunos problemas para volver al repository. Un problema es que Gitlab antes de 8.12 no integró la administración de passwords entre las transferencias SSH para git y las transferencias HTTPS para gfs lfs. Otro problema es la "protección" del proyecto Gitlab, que puede haber visto si usa Gitlab. Vi esto la primera vez que presioné:

 guides.git$ git push X11 forwarding request failed on channel 0 Git LFS: (0 of 105 files) 0 B / 140.38MB http: Post https://gitlab.kucenter.edu/crmda/guides.git/info/lfs/objects/batch: x509: certificate signed by unknown authority http: Post https://gitlab.kucenter.edu/crmda/guides.git/info/lfs/objects/batch: x509: certificate signed by unknown authority error: failed to push some refs to 'git@gitlab.kucenter.edu:crmda/guides.git' 

Hicimos varios cambios para solucionar el problema. Necesitábamos la versión más nueva de Gitlab (8.12.4). Necesitaba decirle a Git que ignorara los certificates desactualizados. En el server de Gitlab, el proyecto tenía que estar "desprotegido" para que los desarrolladores pudieran impulsarlo. No entiendo por qué fue necesario porque soy el propietario y puedo realizar cambios regulares de git, pero aparentemente la integración de lfs es diferente. Después de tanto alboroto, tenemos éxito al volver al repository:

 guides.git$ GIT_SSL_NO_VERIFY=true git push X11 forwarding request failed on channel 0 Git LFS: (0 of 0 files, 105 skipped) 0 B / 0 B, 140.38 MB skipped Counting objects: 866, done. Delta compression using up to 8 threads. Compressing objects: 100% (520/520), done. Writing objects: 100% (866/866), 32.94 MiB | 26.41 MiB/s, done. Total 866 (delta 311), reused 866 (delta 311) To git@gitlab.kucenter.edu:crmda/guides.git + e3327ef...e4ac76a master -> master (forced update) + 74ccc45...6639b24 refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head -> refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head (forced update) 

¡Éxito!

Luego volví al directory de trabajo de este repository, el que tenía los files PDF guardados dentro de él, y probé un git pull. Veo muchos conflictos de fusión que tendré que abordar:

 guides$ git pull X11 forwarding request failed on channel 0 remote: Counting objects: 792, done. remote: Compressing objects: 100% (491/491), done. remote: Total 792 (delta 294), reused 791 (delta 293) Receiving objects: 100% (792/792), 32.92 MiB | 54.09 MiB/s, done. Resolving deltas: 100% (294/294), done. From gitlab.kucenter.edu:crmda/guides + e3327ef...e4ac76a master -> origin/master (forced update) warning: Cannot merge binary files: keyword_guide/guide_keywords.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c) warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs/9._opcion_RP_en_LISREL.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c) warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs/8._Imputacion_de_datos.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c) warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs/7._bootstrap.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c) warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs [...snip out hundnetworkings of those ...] Automatic merge failed; fix conflicts and then commit the result. 

Creo que probablemente haga un clon limpio del control remoto y continúe desde allí. Las instrucciones que encuentro en Internet no ayudan demasiado con eso, se trata principalmente de empezar con lfs, no tanto de lidiar con lfs en curso y clones de lfs. Me preocupa un poco lo que sucedería si alguien clonara esto y no tuvieran lfs. Oh, bueno, ya veremos.

Aquí está mi pregunta Si quisiera lidiar con todos esos conflictos binarys, ¿qué haría? Si simplemente quiero aceptar todos los cambios desde el server, parece que solo necesito ejecutar esto una y otra vez, para cada "FN.pdf" en conflicto.

 $ git checkout --theirs -- fn.pdf $ git add fn.pdf 

Hacer eso una y otra vez parece tedioso, pero supongo que puedo hacerlo.

También encontré consejos aquí ( Resolviendo un conflicto de Git con files binarys ) para probar

 $ git mergetool 

pero no puedo decir con certeza cómo interactuar con él. El diff lanza un marco gvim con 3 columnas de buffers, pero no lo he navegado con éxito. Me parece que me está metiendo en el infierno del editor.

Creo que probablemente haga un clon limpio del control remoto y continúe desde allí.

Correcto, este es el paso más importante después de usar cualquier herramienta, ya sea BFG, filter-branch, etc., que reescribe el historial (y usualmente al hacerlo, por lo que elimina los files no deseados a los que se hace reference en ese historial). La página de inicio de BFG dice:

En este punto, ya está listo para que todos puedan deshacerse de sus copys antiguas del repository y hacer nuevos clones de los nuevos datos pródigos. Lo mejor es eliminar todos los clones antiguos, ya que tendrán un historial sucio que no querrás arriesgar a volver a introducir en tu repository recientemente limpio.

La historia nueva / reescrita será desde algún punto en adelante de la historia (el punto del primer cambio en la reescritura) totalmente divergente de la historia anterior en lo que concierne a Git, porque todos los hash de compromiso desde ese punto en adelante cambiarán. La única manera sensata de proceder es que todos los desarrolladores retiren sus clones actuales de la historia anterior y obtengan nuevos clones. En teoría, podría actualizar estos, pero requeriría mucho cuidado con poco valor.

La eliminación de clones antiguos networkinguce la posibilidad de que alguien presione las references al historial anterior, reintroduciendo el historial anterior y los files no deseados que contenía.