3

我为指定的标签创建了一个浅克隆：

git clone --branch v0.1.3 --depth 1 file:///c/usr/sites/smc .

在此之后，克隆的 repo 中仅包含标签 v0.1.3（和相关文件）。它没有该标记之前或之后的所有更改的历史记录（据我所知 - 如果有错误，请纠正我。）接下来我想更新克隆以包含 v0.1.4。如果我使用“git fetch --unshallow”命令，那么我会得到我不想要的完整历史记录。有没有办法扩展我的克隆以包含来自主人的新历史（如 v0.1.4 和 0.1.5），但不包括旧历史（如 0.1.2）？（我看到一个名为 update-shallow 的选项，但不明白它的作用或是否相关。）

这样做的目标是：

1) 通过不克隆整个 repo，使远程服务器上的存储库的初始设置快速而小。（我们的 repo 主要是二进制文件：DLL、EXE。）

2) 可以将远程 repo 升级到更高版本（由标签给出），但不能升级到更早版本。这样的升级只会转移存储库的一小部分，所以它也应该很快。

注意：我的 Git 版本是 Windows 7 上的 1.9.2.msysgit.0。这包括最近对浅克隆的增强。我们可能会在 Linux 上托管主存储库，但我们部署的代理运行 Windows。目的是使用 puppet 企业管理结帐。

更新：尝试了 VonC 的建议。

$ git fetch --update-shallow origin v0.1.4
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From file:///c/usr/sites/smc
 * tag               v0.1.4     -> FETCH_HEAD

paul.chernoch@USB-XXXXXXXXX /c/usr/sites/smc-clone3 ((v0.1.3))
$ git describe
v0.1.3

paul.chernoch@USB-XXXXXXXXX /c/usr/sites/smc-clone3 ((v0.1.3))
$ git tag --list
v0.1.3

虽然该命令似乎做了一些事情，但我在目标仓库中没有看到标签 v0.1.4。但是，如果我使用 --tags 选项，我会得到所有的标签，还有所有的历史！另外，我不理解 git fetch 命令输出中的符号“FETCH_HEAD”。

更新：进一步的研究表明，这个 SO 问题是在一个类似的目标之后： git shallow clone to specific tag

4

2 回答 2

2

似乎我对此有类似的问题，后来发现了这个。诀窍是在 fetch 命令的末尾和深度指定完整的 refspec。refs/tags/v0.1.3:refs/tags/v0.1.3 或 tag v0.1.3 简称

Git浅获取新标签

git fetch --depth 1 origin tag v0.1.4
于 2014-10-29T14:16:27.267 回答
0

此选项更新.git/shallow并接受此类参考。

但这将在 Git 2.27（2020 年第二季度）中更好地工作，它修复了在提取到一个浅层存储库后的内核不一致问题，该存储库破坏了代码以写出commit-graph。

那也会影响git push。

请参阅Taylor Blau ( ) 的提交37b9dca （ 2020 年 4 月 23 日）和提交 8a8da49（2020 年 4 月 24 日）。（由Junio C Hamano 合并 -- --在2b4ff3d 提交中，2020 年 5 月 1 日）ttaylorr
gitster

shallow.c: 使用' {commit,rollback}_shallow_file'

协助人：Jonathan Tan
协助人：Junio C Hamano
签字人：Taylor Blau
审核人：Jonathan Tan

在bd0b42aed3 (" fetch-pack: do not take shallow lock unnecessarily", 2019-01-10, Git v2.21.0-rc0 -- merge列在第 #4 批中) 中，作者指出 ' is_repository_shallow' 会产生可见的副作用设置' is_shallow'和' shallow_stat'。

这是一个问题，例如，在启用了 ' --update-shallow' 的浅层存储库中使用 ' fetch.writeCommitGraph' 获取，因为对 ' .git/shallow' 的更新将导致 Git 认为存储库不是浅层的，从而绕过提交图兼容性检查.

这会导致浅层存储库中出现问题，其至少具有至少一个祖先的浅层引用（因为客户端不会拥有这些对象，因此在编写 a 时无法对提交进行可达性关闭commit-graph）。

commit_lock_file通过在 ' ' 和 ' ' 上引入薄包装器来解决这个问题，rollback_lock_file以便在锁定被保持在 ' .git/shallow' 上时使用。
这些包装器（适当地称为' commit_shallow_file'和' rollback_shallow_file'）调用它们各自在' lockfile.h'中的函数，但另外重置浅层机器使用的有效性检查。

当持有的锁在 ' ' 文件上时，用 ' ' 和 ' '替换' commit_lock_file' 和 ' '的每个实例。rollback_lock_filecommit_shallow_filerollback_shallow_file.git/shallow

结果，prune_shallow现在只能调用一次''（因为check_shallow_file_for_update调用''后''会死掉reset_repository_shallow）。但是，这没关系，因为我们prune_shallow每个进程最多只调用一次 ' '。

警告，在 Git 2.28（2020 年第三季度）之前，fetch.writeCommitGraph当请求“feature.experimental”时启用了“”，但发现即使对于当前形状的大胆人来说，它也有点太冒险了。

至少目前，该配置已从“实验性”功能集中退出。

请参阅Jonathan Nieder ( ) 的提交 b5651a2（2020 年 7 月 6 日）。（由Junio C Hamano 合并 -- --在提交 9850823中，2020 年 7 月 9 日）artagnon
gitster

experimental：默认为 fetch.writeCommitGraph=false

报告人：Jay Conrod
帮助人：Taylor Blau
签字人：Jonathan Nieder

该fetch.writeCommitGraph功能使 fetches 在 fetch 上为新下载的包写出提交图文件。

这提高了执行修订遍历的各种命令的性能，最终应该成为每个人的默认设置。

为了为未来做准备，默认情况下，设置 feature.experimental=true 的用户会启用它来体验未来的默认设置。

唉，对于--unshallow从浅克隆中提取它遇到了一个障碍：当 Git 提取新对象并正在编写提交图时，它已经执行了修订遍历并r->parsed_objects包含有关提取之前的浅边界的信息。

提交图编写代码小心避免在浅存储库中写入提交图文件，但新状态并不浅，结果是从那时起，“git log”之类的命令会使用新编写的提交图代表具有旧浅边界的虚构历史的文件。

我们可以通过让提交图编写代码更加小心来解决这个问题，以避免编写可能使用任何移植或浅状态的提交图，但是可能还有其他的变异状态片段可能会依赖 fetch 的提交图编写代码上。

所以在 feature.experimental 配置中禁用它。

自 4 月发现此错误以来， Google 开发人员一直在此配置中运行（通过fetch.writeCommitGraph=false在系统配置中进行设置）来解决此错误。

一旦修复落地，我们将fetch.writeCommitGraph=true再次启用它，以便在向更广泛的受众推出之前对其进行一些早期测试。

换句话说：

  • 这个补丁只影响行为feature.experimental=true
  • 它使 feature.experimental 与谷歌过去几个月一直在使用的配置相匹配，这意味着与没有它相比，它会让用户处于更好的测试状态
  • 这应该feature.experimental通过使 feature.experimental 更安全地使用来改进对由 保护的其他功能的测试

另外，仍然使用 Git 2.28（2020 年第三季度），当fetch.writeCommitGraph在浅存储库中设置“”配置并且 fetch 移动了浅边界时，我们写出了与实际不匹配的损坏的提交图文件，这已得到纠正。

请参阅Taylor Blau ( ) 的提交 ce16364（2020 年 7 月 8 日）。（由Junio C Hamano 合并——在提交 24ecfdf中，2020 年 7 月 9 日）ttaylorr
gitster

commit.c：不浅薄时不要坚持替代父母

帮助者：Derrick Stolee
帮助者：Jonathan Nieder
报告者：Jay Conrod
审核者：Jonathan Nieder
签字者：Taylor Blau

从37b9dcabfc ( shallow.c: use ' {commit,rollback}_shallow_file', 2020-04-22) 开始，Git 知道如何重置$GIT_DIR/shallow文件的 stat-validity 检查，允许它在同一进程中在浅层和非浅层状态之间切换（例如，在'git fetch --unshallow'）。

但是，当$GIT_DIR/shallow发生更改时，Git 不会更改或删除内存中的任何移植物（或替代父母）。

这出现在 fetch.writeCommitGraph 设置为 true 的“git fetch --unshallow”中。通常在浅层存储库中（甚至在这种情况下，在37b9dcabfc之前），commit_graph_compatible()将返回 false，表明该存储库不应该用于编写提交图（因为提交图文件不能代表浅层历史）。但是从37b9dcabfc 开始，在 --unshallow 操作中检查成功。

因此，即使存储库不再是浅层（也就是说，我们拥有所有对象），这些对象的核心表示仍然在浅层边界处具有被修改的父级。

当提交图写入继续时，我们使用了不正确的父系，产生了错误的结果。

用户有两种解决方法：(1) 将 'fetch.writeCommitGraph' 设置为 'false'，或 (2) 在 unshallowing 后删除提交图。

解决此问题的一种方法是在 unshallowing 之后完全重置已解析的对象池（刷新缓存，从而防止后续读取修改其父对象）。当调用者对旧池的引用现在已经过时时，这会产生问题，因此这个补丁实现了不同的方法。取而代之的是，将一个新位附加到池中，“ substituted_parent”，它指示存储库是否曾经存储过修改其父级的提交（即，在 unshallowing 之前的浅边界）。

这个位需要粘性，因为在修改提交的父母之后的所有读取在不浅化时都是不可靠的。修改 check in ' commit_graph_compatible' 以考虑到这一点，并正确避免在这种情况下生成提交图，从而解决错误。

于 2020-05-02T19:33:31.433 回答