У нас есть репозиторий, в который мы делали снимки отчетов в формате PDF. Я хочу попробовать git lfs, посмотреть, улучшит ли это качество жизни.
Я выполнил указанные здесь процедуры (https://github.com/rtyley/bfg-repo-cleaner/releases), чтобы использовать BFG для очистки старых двоичных файлов и перехода на lfs. Я наткнулся на пару проблем, связанных с использованием сервера Gitlab для репозитория, но, в конце концов, я считаю, что все прошло хорошо.
Я пишу, чтобы показать, что мы сделали, и задать вопрос об устранении конфликтов слияния в самом конце.
Я покажу вам стенограмму. Мы проверяем клон "--mirror" (голое репо), и BFG делает свою работу с ним, а затем мы возвращаем его обратно после того, как возились с:
guides-to-lfs$ git clone --mirror [email protected]: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
Если вы попробуете это сделать, вы должны быть готовы к некоторым проблемам с возвращением в репо. Одна из проблем заключается в том, что Gitlab до версии 8.12 не интегрировал управление паролями между передачей SSH для git и передачей HTTPS для git lfs. Другая проблема - это «защита» проекта Gitlab, с которой вы могли столкнуться, если использовали Gitlab. Я увидел это в первый раз, когда нажал:
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 '[email protected]:crmda/guides.git'
Мы внесли несколько изменений, чтобы обойти проблему. Нам потребовалась абсолютно последняя версия Gitlab (8.12.4). Мне нужно было сказать Git игнорировать устаревшие сертификаты. На сервере Gitlab проект должен был быть «незащищенным», чтобы разработчики могли протолкнуть его. Я не понимаю, почему это было необходимо, потому что я владелец и могу регулярно вносить изменения в git, но, очевидно, интеграция lfs другая. После этой суеты мы успешно возвращаемся в репозиторий:
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 [email protected]:crmda/guides.git
+ e3327ef...e4ac76a master -> master (forced update)
+ 74ccc45...6639b24 refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head -> refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head (forced update)
Успех!
Затем я вернулся в рабочий каталог этого репозитория, в котором были сохранены файлы PDF, и попробовал выполнить git pull. Я вижу много конфликтов слияния, которые мне нужно решить:
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 hundreds of those ...]
Automatic merge failed; fix conflicts and then commit the result.
Я думаю, что, наверное, просто сделаю чистый клон пульта ДУ и продолжу дальше. Инструкции, которые я нахожу в Интернете, не слишком помогают в этом, они в основном касаются начала работы с lfs, а не столько о работе с текущими lfs и клонами lfs. Я немного беспокоюсь о том, что произойдет, если кто-нибудь клонирует эту штуку, а у них не будет lfs. Ну что ж, посмотрим.
Вот мой вопрос. Если бы я действительно хотел разобраться со всеми этими двоичными конфликтами, что бы я делал? Если я просто хочу принять все изменения с сервера, мне просто нужно запускать это снова и снова, один раз для каждого конфликтующего файла "fn.pdf".
$ git checkout --theirs -- fn.pdf
$ git add fn.pdf
Делать это снова и снова кажется утомительным, но, думаю, я справлюсь.
Я также нашел здесь совет (Разрешение конфликта Git с двоичными файлами ) пытаться
$ git mergetool
но я не могу точно сказать, как с ним взаимодействовать. Функция diff запускает фрейм gvim с 3 столбцами буферов, но я не смог успешно пройти по нему. Мне кажется, это ввергает меня в редакторский ад.
