一种方法来保持浅的git克隆只是最低限度的最新？ [英] A way to keep a shallow git clone just minimally up to date?

问题描述

我的目标是能够建立最近的版本，并为一个有着悠久历史悠久历史的项目做出贡献 - 并且在不使用本地存储重复大量历史分支和历史的情况下执行此操作可以追溯到十年还有更多（我总是可以在项目中央存储库的Web UI中查找，如果需要的话，我可能不会这样做）。

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

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

这给了我一个整洁的本地克隆， ' master '分支，并且足够承诺覆盖最近的两个标记版本。

然后我可以执行' git结帐latest-release-tag '并构建最新版本。 Yippee！

按照我的预期，我需要做一个补丁。一切顺利：' git checkout -b my-patch-branch '，进行我的更改，提交，并且我能够将my-patch-branch恢复到克隆在github上，所以这个项目可以把它拉出来。简单！

我认为我在那里很幸运，因为从我阅读的内容中，例如，我不会在git 1.9之前做到这一点。

但是安装的版本竟然是1.9，所以我逃脱了它现在

现在我想要做的下一个显而易见的事情是从远程获取并获取master上最近的活动（包括我的补丁的上游合并，所以我不再需要该分支）。我尝试了'git fetch --dry-run upstream'，并且惊恐地看着它下载了无尽的兆字节的下载，然后给了我一个回到乳齿象年龄的新标签列表。我很高兴我说了 - 干运行！

我真的希望能拿起自从我的克隆的HEAD以来，我在' master '上提交了大约12次左右的新提交，然后我可能会有一个深度为52的克隆而不是40，但这就是我希望......在我参与其中之前，从最近有用的历史开始，然后从这一点开始跟踪并发展，并能够构建，分支和推送补丁程序。看起来如此接近。

有没有简单的方法让git做我想做的事情？

编辑：更多信息。

（1）upsteam实际上超过了我接近一百次提交，我估计有一打已被撤销。

（2）原来的40次提交都是单亲提交。我试图获取的一些后来的是与我的克隆没有包含的某个分支中的第二个父级合并提交。那么这些人是否会让git吸收他们所有的古代历史，因为我的克隆中最早的提交并不是一个共同的祖先？

有没有办法告诉它我不希望这样？

更多新信息：

（1）我想到我之前使用的是http协议，它实际上并未与git进程交互服务器，所以它没有机会定制下载大小。

但是，当我使用git-over-ssh重试时，我仍然有一个巨大的获取。

然后

（2），像动物一样，我点击了github的newtork显示中显示的合并提交，找到了涉及在浅剪切之前开始的分支的合并提交，并将他们的父-2 SHA添加到了我的 .git / shallow 文件，然后然后再次通过ssh尝试'git fetch'。这很好，并下载了一个小包文件，可以快速转发我的本地 master 分支。我认为这正是我希望git能够自动完成的操作，但我还没有找到办法。手动，这是非常乏味。 ：）

解决方案

我应该传递什么值？如果我最初克隆的深度为40，上游有100个新的提交，我是否要求深度140？

Git 2.11（2016年第4季度）可让您增加深度，因此如果您的抓取带来了100个新提交，您可以将新的深度设置为140

请参阅提交cccf74e ，提交079aa97 ， commit 2997178 ， commit cdc3727 ， commit 859e5df ， commit a45a260 ， commit 269a7a8 ，提交41da711 ，< a href =https://github.com/git/git/commit/6d43a0cefd769c650bd114f41434ef5a7aa998e7 =nofollow> commit 6d43a0c ， commit 994c2aa ， commit 508ea88 ，提交569e554 ， commit 3d9ff4d ， commit 79891cb a>， commit 1dd73e2 a>，提交0d789a5 ， commit 45a3e52 ， commit 3f0f662 ，提交7fcbd37 ， commit 6e414e3 （2016年6月12日）作者：Nguyễn TháiNgọcDuy（ pclouds ）。

帮助： Duy Nguyen（ pclouds ）， Eric Sunshine（ sunshineco ）和 Junio C Hamano（ gitster ）。

^{（由 gitster - / a460ea4a3cb1dad253604b5e2aeaa161637453a9rel =nofollow> commit a460ea4 ，2016年10月10日）} commit cccf74e ：

fetch ， upload-pack ： - deepen = N 边界由 N 提交

在 git fetch ， - depth 参数总是相对的与最新的远程参考。

这使得它有点难以覆盖这个用例，用户想要做出更浅的历史，比如说3级更深。

它可以工作如果远程引用没有移动y但是没有人能保证，特别是当这个用例在最后一个克隆或 git fetch --depth >后几个月执行时。

另外，使用 - depth 修改浅边界不适用于由创建的克隆 - 自或 - 不是。

这个补丁修复了这个问题。

一个新参数 - deepen =< N> 将增加< N> 更多（*）父级提交到当前历史记录，而不管远程引用（*）我们甚至可以支持 - deepen =< N> 其中< N> 是负数。

在这种情况下，我们可以从浅克隆中删除一些历史记录。这个操作
（和 - depth =< depth depth> ）不需要与远程端进行交互（因此实现起来更复杂） / p>




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).

这篇关于一种方法来保持浅的git克隆只是最低限度的最新？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！