0

我正在将现有的存储库迁移到 git lfs，似乎我设法创造了一场完美的风暴。

目前有两台机器：A和B。

机器 A 缺少文件 X 的内容。调用git lfs fetch --all origin. 机器 B 缺少文件 Y 的内容。

我尝试调用git lfs push --all origin两者。它在机器 A 上不起作用，因为它没有文件 X。它在机器 B 上不起作用，因为它没有文件 Y。

我怎么可能解决这种情况。我不知道这是怎么发生的，甚至可能发生。

git lfs push在其中一台机器上的输出：

Git LFS: (0 of 982 files, 1300 skipped) 0 B / 1.73 GB, 1.09 GB skipped         
d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006 does not 
exist in .git/lfs/objects. Tried 
Assets/weapons/models/at_mine/textures/1k/at_mine__normal_1k.bmp, which 
matches d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006.

git lfs fetch在其中一台机器上的输出：

git lfs fetch --all
Scanning for all objects ever referenced...
* 2319 objects found
Fetching objects...
Git LFS: (207 of 207 files, 722 skipped) 524.01 MB / 524.51 MB, 870.82 MB 
skipped
[d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006] Object 
does not exist on the server: [404] Object does not exist on the server
[df1dbb12f35f5392c157beebbc3613f70993c691a68f4cc65033ade528de3418] Object 
does not exist on the server: [404] Object does not exist on the server
[edaf4f6721fb14ce4d38d3adddc86aaaf6fbf0c7db11da451022a4f74af97f30] Object does not exist on the server: [404] Object does not exist on the server
... and so on and so on

我正在使用 bfg repo 清洁器执行到 LFS 的迁移。

** 编辑 **

我执行的步骤：

  1. 以旧形式（从转换之前）到机器 A 的整个 repo 的 Git 克隆。
  2. 我在机器 A 上运行 BFG，它基本上重写了主分支的历史（没有其他分支远程保存）。
  3. 我git push origin master --force按照你应该用新版本的 master 替换旧版本的 master 来运行。
  4. 我git fetch在机器 B 上运行以获取所有文件。
  5. 机器 B 上有一些提交，在 master 中尚未发送到服务器 - 因为它们会导致 repo 超出配额。因此，我运行git rebase --onto origin/master HEAD~3 HEAD将未发送的新提交移动到新版本的 master。
  6. 我git push origin master在机器 B 上运行。

这就是我现在的位置。

4

2 回答 2

0

所以，显然整个麻烦源于我使用 BFG 转换我的存储库这一事实。不要这样做。据我所知，它可能会破坏您的存储库，就像它破坏我的方式一样。使用 git-lfs-migrate。

我最初使用 BFG 是因为它更容易理解如何使用它。但是，如果您碰巧触摸或分支提交中的任何内容，而不是最新提交，则不将 .gitattributes 放入重写的提交中会产生不利影响，这会导致各种问题。您还必须格外小心地手动更改 .gitattributes 以匹配 BFG 命令。

基本上不要为此使用 BFG，没有理由这样做。

首先也是最重要的：在尝试重写历史之前进行备份。并确保你这样做是正确的，因为 Bitbucket.org 和一些类似网站中的分叉不能正确处理 LFS。

于 2017-04-07T16:25:47.927 回答
0

所以这可能与 LFS 对象的状态无关，但可能会导致清理尝试出现一些问题。您为机器 B 显示的 rebase 命令使您处于一种有点尴尬的状态。如果你原来有

A --- B --- C --- D <--(master)

然后你获取了重写的结果，给出

A --- B --- C --- D <--(master)

A' --- B' <--(origin/master)

您指定的变基命令，因为它列为HEAD要变基的参考，因此会使您处于分离的头部状态

A --- B --- C --- D <--(master)

A' --- B' <--(origin/master)
        \
         C' --- D' <--(HEAD)

master所以无论 LFS 有什么问题，推送都应该失败。如果你想跟踪D某种类型的清理后验证，你可以标记它；然后HEAD仍然在D'运行

git branch -f master

要得到

A --- B --- C --- D <--[old-master])

A' --- B' <--(origin/master)
        \
         C' --- D' <--(master)

但就像我说的，如果每台机器都缺少一些 LFS 对象，那么这将无法解决这个问题。现在我假设两台机器都正确配置了git-lfs. lfs install如果在需要的时候没有运行，我已经看到了相当奇怪的行为；但除非你在做一些不起眼的事情，否则不太可能导致你在哪里......所以......

因为 LFS 对象是使用 SHA-256 标识的，所以具有匹配 id 的两个文件是同一个文件是一个非常安全的假设。因此，您可以尝试的一件事是在.git/lfs/objects机器 A 下找到机器 B 中缺少的文件，然后手动复制它。（反之亦然。）如果在两者之间，你有一套完整的 LFS 对象，那么这种情况可以通过这种方式解决。

要查找 ID 为 d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006 的对象，您将查看.git/lfs/objects/d8/d0/d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006

如果两台机器上都缺少一个对象，那么您可以尝试从原始存储库中找出相应的文件，并将其手动添加到本地 LFS 缓存之一。 

git lfs clean <original.file
于 2017-04-07T15:51:41.597 回答