git lfs bfg: 之后，如何解决冲突？
git lfs bfg: after that, resolve conflicts how?
我们有一个存储库，我们在其中提交了报告的 PDF 快照。我想试试gitlfs，看看能不能提高生活质量。
我按照此处 (https://github.com/rtyley/bfg-repo-cleaner/releases) 的过程使用 BFG 清除旧的二进制文件并过渡到 lfs。我经历了一些与使用 Gitlab 服务器作为存储库相关的问题，但最终我相信一切顺利。
我写信是为了展示我们做了什么，并在最后问了一个关于清理合并冲突的问题。
我给你看成绩单。我们检查了一个“--mirror”克隆（一个裸仓库），BFG 在上面做了它的工作，然后我们在摆弄之后把它推回去：
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
如果你尝试这个，你应该准备好在推送时遇到一些麻烦
回到回购协议。一个问题是 8.12 之前的 Gitlab 没有在 git 的 SSH 传输和 git lfs 的 HTTPS 传输之间集成密码管理。另一个问题是 Gitlab 项目 "protection"，如果您使用 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 'git@gitlab.kucenter.edu:crmda/guides.git'
我们做了一些更改来解决这个问题。
我们需要绝对最新版本的 Gitlab (8.12.4)。我需要告诉 Git 忽略过时的证书。在 Git 实验室服务器上，项目必须 "unprotected" 以便开发人员可以推送。我不明白为什么这是必要的，因为我是所有者，我可以推送常规 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 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)
成功！
然后我回到这个存储库的工作目录，其中保存了 PDF 文件的目录，并尝试 git 拉取。我看到很多我必须解决的合并冲突：
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.
我 认为 我可能只会制作一个干净的遥控器克隆，然后从那里继续。我在 Internet 上找到的说明对此没有太大帮助，它们主要是关于 lfs 的入门，而不是关于处理正在进行的 lfs 和 lfs 的克隆。我有点担心如果有人克隆了这个东西但他们没有 lfs 会发生什么。哦，好吧，我们拭目以待。
这是我的问题。如果我真的想处理所有这些二元冲突，我会怎么做？如果我只是想接受来自服务器的所有更改，看来我只需要一遍又一遍地 运行 ，每个冲突一次 "fn.pdf".
$ git checkout --theirs -- fn.pdf
$ git add fn.pdf
一遍又一遍地这样做似乎很乏味，但我想我可以做到。
我也在此处 (Resolving a Git conflict with binary files) 找到了尝试
的建议
$ git mergetool
但我不确定如何与它交互。 diff 东西启动了一个带有 3 列缓冲区的 gvim 框架，但我没有成功导航它。在我看来，这让我陷入了编辑地狱。
I think I'll probably just make a clean clone of the remote and go on from there.
是的，这是使用任何工具后最重要的一步，无论是 BFG、filter-branch 等，它都会重写历史记录（通常这样做是删除该历史记录中引用的不需要的文件）。 BFG 主页说：
At this point, you're ready for everyone to ditch their old copies of the repo and do fresh clones of the nice, new pristine data. It's best to delete all old clones, as they'll have dirty history that you don't want to risk pushing back into your newly cleaned repo.
就 Git 而言，new/rewritten 历史将从历史的某个点（重写中第一个更改的点）开始，与旧历史完全不同，因为从那时起所有的提交散列都会改变。唯一明智的做法是让所有开发人员淘汰旧历史的当前克隆并获得新的克隆。理论上你可以更新这些，但它需要非常小心，没有太大价值。
删除旧的克隆减少了某人推送对旧历史的引用的机会，从而重新引入旧历史及其包含的不需要的文件。
我们有一个存储库，我们在其中提交了报告的 PDF 快照。我想试试gitlfs，看看能不能提高生活质量。
我按照此处 (https://github.com/rtyley/bfg-repo-cleaner/releases) 的过程使用 BFG 清除旧的二进制文件并过渡到 lfs。我经历了一些与使用 Gitlab 服务器作为存储库相关的问题，但最终我相信一切顺利。
我写信是为了展示我们做了什么，并在最后问了一个关于清理合并冲突的问题。
我给你看成绩单。我们检查了一个“--mirror”克隆（一个裸仓库），BFG 在上面做了它的工作，然后我们在摆弄之后把它推回去：
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
如果你尝试这个，你应该准备好在推送时遇到一些麻烦 回到回购协议。一个问题是 8.12 之前的 Gitlab 没有在 git 的 SSH 传输和 git lfs 的 HTTPS 传输之间集成密码管理。另一个问题是 Gitlab 项目 "protection"，如果您使用 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 'git@gitlab.kucenter.edu:crmda/guides.git'
我们做了一些更改来解决这个问题。 我们需要绝对最新版本的 Gitlab (8.12.4)。我需要告诉 Git 忽略过时的证书。在 Git 实验室服务器上，项目必须 "unprotected" 以便开发人员可以推送。我不明白为什么这是必要的，因为我是所有者，我可以推送常规 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 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)
成功！
然后我回到这个存储库的工作目录，其中保存了 PDF 文件的目录，并尝试 git 拉取。我看到很多我必须解决的合并冲突：
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.
我 认为 我可能只会制作一个干净的遥控器克隆，然后从那里继续。我在 Internet 上找到的说明对此没有太大帮助，它们主要是关于 lfs 的入门，而不是关于处理正在进行的 lfs 和 lfs 的克隆。我有点担心如果有人克隆了这个东西但他们没有 lfs 会发生什么。哦，好吧，我们拭目以待。
这是我的问题。如果我真的想处理所有这些二元冲突，我会怎么做？如果我只是想接受来自服务器的所有更改，看来我只需要一遍又一遍地 运行 ，每个冲突一次 "fn.pdf".
$ git checkout --theirs -- fn.pdf
$ git add fn.pdf
一遍又一遍地这样做似乎很乏味，但我想我可以做到。
我也在此处 (Resolving a Git conflict with binary files) 找到了尝试
的建议$ git mergetool
但我不确定如何与它交互。 diff 东西启动了一个带有 3 列缓冲区的 gvim 框架，但我没有成功导航它。在我看来，这让我陷入了编辑地狱。
I think I'll probably just make a clean clone of the remote and go on from there.
是的，这是使用任何工具后最重要的一步，无论是 BFG、filter-branch 等，它都会重写历史记录（通常这样做是删除该历史记录中引用的不需要的文件）。 BFG 主页说：
At this point, you're ready for everyone to ditch their old copies of the repo and do fresh clones of the nice, new pristine data. It's best to delete all old clones, as they'll have dirty history that you don't want to risk pushing back into your newly cleaned repo.
就 Git 而言，new/rewritten 历史将从历史的某个点（重写中第一个更改的点）开始，与旧历史完全不同，因为从那时起所有的提交散列都会改变。唯一明智的做法是让所有开发人员淘汰旧历史的当前克隆并获得新的克隆。理论上你可以更新这些，但它需要非常小心，没有太大价值。
删除旧的克隆减少了某人推送对旧历史的引用的机会，从而重新引入旧历史及其包含的不需要的文件。