一种使浅层 git 克隆保持最新的方法? [英] A way to keep a shallow git clone just minimally up to date?

查看:39
本文介绍了一种使浅层 git 克隆保持最新的方法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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

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

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

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

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

我真的希望它能够在master"上获得十几个左右的新提交,因为我的克隆的 HEAD,然后也许我会有一个深度为 52 的克隆而不是 40,但这正是我想要的......在我参与之前从大量有用的近期历史开始,然后从那时开始跟踪和发展,并且能够构建、分支和推送补丁.好像很近.

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

更多信息.
(1) 上游实际上比我领先近一百次提交,我估计的十几个被取消了.
(2) 原来我用我的克隆获得的原始 40 次提交都是单亲提交.我试图获取的一堆后来的提交是与我的克隆未包括的某个分支中的第二个父级的合并提交.因为我的克隆中最早的提交不是共同的祖先,所以这些是否会导致 git 提取他们所有的古老历史?
有没有办法告诉它我不想要那样?

更多新信息:
(1) 我突然想到我之前使用的是 http 协议,它实际上并不与服务器上的 git 进程交互,因此没有机会定制下载大小.
然而,当我重试使用 git-over-ssh 时,我仍然得到了一个巨大的 fetch.
那么
(2) 像动物一样,我手动点击 github 的newtork"显示中显示的合并提交,找到涉及在我的浅切之前开始的分支的那些,并将它们的 parent-2 SHA 添加到我的 .git/浅 文件,然后然后 再次尝试通过 ssh 'git fetch'.效果很好,并下载了一个小包文件,它可以快进我本地的 master 分支.我认为这正是我希望 git 能够自动执行的操作,但我还没有找到方法来做到这一点.手动的,挺麻烦的.:)

解决方案

我应该传递什么值?如果我最初在深度 40 处克隆并且上游有 100 个新提交,我是否要求深度为 140?

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

请参阅提交 cccf74ecommit 079aa97, 提交 2997178提交 cdc3727commit 859e5df, 提交rel="nofollow noreferrer">提交 a45a260commit 41da711, commit3a0cer>, 提交 994c2aa, 提交 508ea88, 提交 3d9ff4dcommit 79891cb, commit 1dd73e2, 提交 0d789a5, nofollow noreferrer">提交提交 45a3e52, 提交 3f0f662, commit 7fcbd37, commit 7fcbd37a"nofollow noreferrer">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 --commit a460ea4,2016 年 10 月 10 日)

特别是,提交 cccf74e:

<块引用>

fetch, upload-pack: --deepen=N 通过 N 次提交扩展浅边界H2>

git fetch 中,--depth 参数始终与最新的远程引用相关.
这使得覆盖这个用例有点困难,用户想要制作浅历史,比如更深的 3 个级别.
如果远程引用尚未移动,它会起作用,但没有人可以保证,尤其是在最后一次克隆或git fetch --depth"之后几个月执行该用例时.
此外,使用 --depth 修改浅边界不适用于由 --since--not 创建的克隆.

这个补丁修复了这个.
一个新的参数 --deepen= 将添加 更多 (*) 个父提交到当前历史记录,而不管远程引用在哪里.>

(*) 我们甚至可以支持 --deepen= 其中 是负数.
在这种情况下,我们可以从浅克隆中删除一些历史记录.这个操作(和 --depth=)不需要与远程端交互(因此实现起来更复杂).

<小时>

在 Git 2.27(2020 年第 2 季度)之前,git pull"与底层git fetch"共享许多选项,但其中一些没有记录,其中一些传下去是有意义的,但没有传下去.

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

git pull --deepen=x

参见 commit 13ac5edcommit f05558f(2020 年 3 月 28 日)由 René Scharfe (rscharfe).
(由 Junio C Hamano 合并 -- gitster --commit 9f471e4,2020 年 4 月 22 日)

<块引用>

pull:通过记录的获取选项

报告人:天几
签字人:René Scharfe

获取选项 --deepen, --negotiation-tip, --server-option, --shallow-exclude--shallow-since 记录在 git pull 也是如此,但实际上并未被该命令接受.

传递它们以使代码与其文档相匹配.

My aim is to be able to both build recent versions of, and contribute to, a project that has a long and voluminous history - and to do this without using local storage to duplicate lots of historic branches and history going back a decade and more (which I can always look up in the web UI of the project's central repository anyway, if I ever need to, which I probably won't).

I seemed to get lucky with my first try:

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

That gave me a tidy local clone of 'what' that only had the 'master' branch, and enough commits to cover the most recent two tagged releases.
I could then do 'git checkout latest-release-tag' and build the latest release. Yippee!

As I sort of expected, I needed to make a patch. Everything went swimmingly: 'git checkout -b my-patch-branch', make my changes, commit, and I was able to push my-patch-branch back to a clone on github so the project could pull it. Easy!
I think I got lucky there because from what I read, e.g., here, I would not have been able to do that before git 1.9.
But the installed version turned out to be 1.9, so I got away with it.

Now the next obvious thing I'd like to do is fetch from the remote and pick up the most recent activity on master (including the upstream merge of my patch, so I won't need that branch any more). I tried 'git fetch --dry-run upstream' and watched in horror as it ticked off endless megabytes of download and then gave me a list of new tags going back to the age of mastodons. I'm glad I said --dry-run!

I was really hoping it would just pick up the dozen or so new commits on 'master' since the HEAD of my clone, and then maybe I'd have a depth 52 clone instead of 40, but that's kind of what I want ... start with a useful amount of recent history before I became involved, then just track and grow from that point, and be able to build, branch, and push patches. It seems so close.

Is there any simple way to make git do what I'm trying to do? Is what I'm trying to do unreasonable?

Edit: a bit more information.
(1) the upsteam is actually ahead of me by closer to a hundred commits, my estimate of a dozen was pulled out of the air.
(2) it turns out the original 40 commits that I got with my clone were all single-parent commits. A bunch of the later ones that I'm trying to fetch are merge commits with a second parent in some branch my clone didn't include. Could those be causing git to pull in all their ancient history because the earliest commit in my clone isn't a common ancestor?
Is there a way to tell it I don't want that?

More new information:
(1) it occurred to me that I was using the http protocol earlier, which doesn't actually interact with a git process on the server so it has no opportunity to tailor the download size.
However, when I retried using git-over-ssh, I still got a huge fetch.
Then
(2) manually, like an animal, I clicked through the merge commits shown in github's 'newtork' display, found the ones involving branches that began before my shallow cut, and added their parent-2 SHAs to my .git/shallow file, and then tried 'git fetch' over ssh again. That worked great and downloaded a tiny pack file that could just fast-forward my local master branch. I think this is exactly the operation I'd like git to be able to do automatically, but I haven't found a way to do it. Manually, it's pretty tedious. :)

解决方案

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 (Q4 2016) will allow you to increase the depth, so if your fetch does bring 100 new commits, you can set the new depth to 140

See 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 (12 Jun 2016) by Nguyễn Thái Ngọc Duy (pclouds).
Helped-by: Duy Nguyen (pclouds), Eric Sunshine (sunshineco), and Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit a460ea4, 10 Oct 2016)

In particular, 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).


Before Git 2.27 (Q2 2020), "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down.

That means you can deepen your repo history and update your current branch all in one command:

git pull --deepen=x

See commit 13ac5ed, commit f05558f (28 Mar 2020) by René Scharfe (rscharfe).
(Merged by Junio C Hamano -- gitster -- in commit 9f471e4, 22 Apr 2020)

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.

这篇关于一种使浅层 git 克隆保持最新的方法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆