git - 一种使浅层 git 克隆保持最低限度最新状态的方法？

Question

我的目标是能够构建具有悠久而庞大历史的项目的最新版本并为其做出贡献 - 并且在不使用本地存储来复制大量历史分支和十年前历史的情况下做到这一点以及更多(如果我需要的话，我总是可以在项目的中央存储库的 Web UI 中查找，但我可能不会这样做)。

我的第一次尝试似乎很幸运:

git clone --depth 40 -b master http://github.com/who/what.git/ what

这给了我一个整洁的“what”本地克隆，它只有“master”分支，以及足够的提交来涵盖最近的两个标记版本。
然后我可以执行“git checkout latest-release-tag”并构建最新版本。 Yippee!

正如我预料的那样，我需要制作一个补丁。一切进展顺利:'git checkout -b my-patch-branch'，进行更改，提交，然后我能够将 my-patch-branch 推回 github 上的一个克隆，这样项目就可以 pull 它。简单!
我想我在那里很幸运，因为从我读到的内容来看，例如 here ，在 git 1.9 之前我无法做到这一点。
但是安装的版本竟然是1.9，所以我侥幸逃脱了。

现在我想做的下一件显而易见的事情是从远程获取并获取 master 上的最新事件(包括我的补丁的上游 merge ，所以我不需要那个分支)。我尝试了“git fetch --dry-run upstream”并惊恐地看着它完成了无数兆字节的下载，然后给了我一个可以追溯到乳齿象时代的新标签列表。我很高兴我说了 --dry-run!

我真的希望它能从我的克隆的 HEAD 开始接收关于“master”的十几个新提交，然后也许我会有一个深度为 52 的克隆而不是 40 ，但这正是我想要的……在我参与之前从大量有用的近期历史开始，然后从那一点开始跟踪和发展，并能够构建、分支和推送补丁。看起来很接近。

有什么简单的方法可以让 git 做我想做的事情吗？我想做的事情不合理吗？

编辑:更多信息。
(1) 上游实际上比我领先了将近一百个提交，我估计的一打是空话。
(2) 事实证明，我通过克隆获得的原始 40 次提交都是单亲提交。我试图获取的一些后来的是与我的克隆不包括的某个分支中的第二个父级的 merge 提交。这些是否会导致 git 提取他们所有的古老历史，因为我的克隆中最早的提交不是一个共同的祖先？
有没有办法告诉它我不想要那样？

更多新信息:
(1) 我想到我之前使用的是 http 协议(protocol)，它实际上并没有与服务器上的 git 进程交互，所以它没有机会调整下载大小。
然而，当我重试使用 git-over-ssh 时，我仍然得到了一个巨大的获取。
然后
(2) 手动地，像动物一样，我点击了 github 的“newtork”显示中显示的 merge 提交，找到了涉及在我的浅切之前开始的分支的提交，并将它们的 parent-2 SHA 添加到我的 .git/浅 文件，然后 再次尝试通过 ssh 进行“git fetch”。效果很好，下载了一个小包文件，可以快进我的本地 master 分支。我认为这正是我希望 git 能够自动完成的操作，但我还没有找到一种方法来做到这一点。手动，这很乏味。 :)

Answer 1

What value should I pass? If I originally cloned at depth 40 and there are 100 new commits upstream, do I ask for depth 140?

Git 2.11(2016 年第 4 季度)将允许您增加深度，因此如果您的提取确实带来了 100 个新提交，您可以将新深度设置为 140

参见 commit cccf74e , commit 079aa97 , commit 2997178 , commit cdc3727 , commit 859e5df , commit a45a260 , commit 269a7a8 , commit 41da711 , commit 6d43a0c , commit 994c2aa , commit 508ea88 , commit 569e554 , commit 3d9ff4d , commit 79891cb , commit 1dd73e2 , commit 0d789a5 , commit 45a3e52 , commit 3f0f662 , commit 7fcbd37 , commit 6e414e3 (2016 年 6 月 12 日)作者:Nguyễn Thái Ngọc Duy ( pclouds ) .
帮助:Duy Nguyen ( pclouds ) , Eric Sunshine ( sunshineco ) , 和 Junio C Hamano ( gitster ) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit a460ea4 ，2016 年 10 月 10 日)}

特别是，commit cccf74e :

fetch, upload-pack: --deepen=N extends shallow boundary by N commits

In git fetch, --depth argument is always relative with the latest remote refs.
This makes it a bit difficult to cover this use case, where the user wants to make the shallow history, say 3 levels deeper.
It would work if remote refs have not moved yet, but nobody can guarantee that, especially when that use case is performed a couple months after the last clone or "git fetch --depth".
Also, modifying shallow boundary using --depth does not work well with clones created by --since or --not.

This patch fixes that.
A new argument --deepen=<N> will add <N> more (*) parent commits to the current history regardless of where remote refs are.

(*) We could even support --deepen=<N> where <N> is negative.
In that case we can cut some history from the shallow clone. This operation (and --depth=<shorter depth>) does not require interaction with remote side (and more complicated to implement as a result).

---

在 Git 2.27(2020 年第 2 季度)之前，“git pull ” 与基础“git fetch ” 共享许多选项，但其中一些未记录在案，而一些可以传递的选项没有传递。

这意味着您可以在一个命令中加深您的 repo 历史并更新您当前的分支:

git pull --deepen=x

参见 commit 13ac5ed , commit f05558f (2020 年 3 月 28 日)René Scharfe ( rscharfe ) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 9f471e4 ，2020 年 4 月 22 日)}

pull: pass documented fetch options on

^{Reported-by: 天几
Signed-off-by: René Scharfe}

The fetch options --deepen, --negotiation-tip, --server-option, --shallow-exclude, and --shallow-since are documented for git pull as well, but are not actually accepted by that command.

Pass them on to make the code match its documentation.