小编Flo*_*ter的帖子

Boost Format 文档说：

它的目标之一是提供 printf 的替代品，这意味着 format 可以解析为 printf 设计的格式字符串，将其应用于给定的参数，并产生与 printf 相同的结果。

当我使用相同的格式字符串比较 boost:format 和 printf 的输出时，我得到了不同的输出。在线示例在这里

#include <iostream>
#include <boost/format.hpp>

int main()
{
    boost::format f("BoostFormat:%d:%X:%c:%d");

    unsigned char cr =65; //'A'
    int cr2i = int(cr);

    f % cr % cr % cr % cr2i;

    std::cout << f << std::endl;
    printf("Printf:%d:%X:%c:%d",cr,cr,cr,cr2i);
}

输出是：

升压格式： A:A:A:65

打印输出： 65:41:A:65

不同之处在于当我想将字符显示为整数类型时。

为什么有区别？这是一个错误还是想要的行为？

使用GIT LFS时，.gitattributes控制哪些文件由 GIT LFS 管理，哪些文件不由 GIT LFS 管理。根据文档，在 GIT LFS 和常规GIT存储之间移动文件所需的只是更改.gitattributes.

.gitattributes我在 Bitbucket 存储库中进行了修改，但git lfs ls-files仍然列出了与以前相同的文件，包括不应再由 GIT LFS 管理的文件，不包括现在应由 GIT LFS 管理的文件。此外，提交和推动变革的速度.gitattributes快得令人怀疑。

是否有一个命令我可以（或必须）运行来更新所有文件的GIT LFS状态并将它们移动到正确的存储？

我在 Bitbucket 中有一个 GIT 存储库，它使用 GIT-LFS：

每当我尝试克隆存储库时，git-lfs.exe都会遇到以下命令行：

"C:\Program Files\Git\mingw64\bin\git-lfs.exe" filter-process

在以下所有情况下都会发生这种情况：

1. 当我尝试克隆存储库目录时（使用git clone https://...）
2. 当我尝试将存储库添加为子模块时（运行时git submodule update）
3. 在我中止上述任何命令并git reset --hard使用 GIT-LFS 在存储库的克隆中运行（然后缺少文件和更改）。

我在用

$ git-lfs --version
git-lfs/3.1.2 (GitHub; windows amd64; go 1.17.6)
$ git --version
git version 2.35.1.windows.2

并且也遇到了同样的问题

$ git-lfs --version
git-lfs/2.12.1 (GitHub; windows amd64; go 1.14.10; git 85b28e06)

我还有其他几个工作目录，其中同一个存储库是一个子模块，并且git submodule update在这些目录中运行正常（但没有任何更改，因此该命令实际上不必执行任何操作）。

更新：按照此答案中的建议启用跟踪并等待足够长的时间后，结果发现 GIT LFS 在从 LFS 下载实际文件时“卡住”，这似乎非常慢（尽管文件的总大小是仅约 1 GB。文件日期显示总下载时间超过 1.5 小时！）。它最终完成，所有文件都在它们应该在的地方。这可能是与 Bitbucket 相关的问题。关于可能导致此问题的任何建议（除了联系 Atlassian 支持人员之外）？

（任何有关如何调试此问题的建议也是有效的答案）