如何知道git的浅层克隆的深度? [英] how to know the depth of a git's shallow clone?

查看:134
本文介绍了如何知道git的浅层克隆的深度?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

例如,如果我检索到浅表克隆,则

git clone --depth 10 http://foo.bar/baz.git

git是否有任何命令来检索此克隆的深度? (例如,仅显示10的命令).

解决方案

简短答案:否.该数字不会存储在任何地方(除非您自己存储它-如果Git将其保存在.git/config的某个地方可能会很好).

仅当文件.git/shallow存在时,存储库较浅(根据Git的内部定义).该文件的内容有点偷偷摸摸:大多数Git都以与.git/grafts完全相同的方式对待它.也就是说,shallow文件中的每一行都包含一个提交哈希ID(除了grafts之外,没有其他内容,其中每一行后都有所有嫁接的父ID:由于该行为空,因此没有父ID和提交将成为根提交). (Git可以在内部将其标记为不是真正的根",表明它具有从未获得的父代.要完全可靠,这还需要确保没有 actual 根提交ID.曾经存储在文件中,我不确定是否是这种情况.)

您可以计算所有参考的最大深度:从每个参考开始,计算从最尖端的提交到(可能是嫁接的)根的图形深度.但是,这不一定是传递给--depth的数字(此处或以后将--depth赋予git fetch).

例如,假设我们克隆一个只有两次提交的存储库,同时也使用--depth 10.最深的链是一个或两个提交长的时间,因为只有两个提交:一个确定的(真正的)根,另一个可能以另一个作为其父对象的提交,或者可能是另一个(真正的)根提交.如果(我不知道答案是这种情况).git/shallow文件从不包含真实根,则此时该文件将为空,并且我们知道无论最长的链条有多长,--depth参数都必须具有大于这个数字,但我们不知道实际数字.

另一方面,假设我们使用--depth 10克隆了10个或更多提交的存储库,并获得了10条由假根植终止的提交链.然后,我们向这条10长链添加两个 new 提交,这样我们就有了12条提交链. --depth仍然是10,但算上链,我们发现是12.

因此,这显示了两种方法,即计算的计数可能太小或太大.但是,在许多情况下,计算出的计数会很好地工作.要获取计算的计数,请使用git for-each-ref查找每个引用,并使用git rev-list --count --first-parent查找每个引用.无论您获得的最大值是多少,都可能是深度数,或者是足够接近的深度.

If I retrieve a shallow clone, e.g.

git clone --depth 10 http://foo.bar/baz.git

Does git have any command to retrieve the depth of this clone? (e.g. a command that simply prints 10).

解决方案

Short answer: no. The number is not stored anywhere (unless you store it yourself—and it might be nice if Git saved it in .git/config somewhere).

A repository is shallow (by Git's internal definition) if and only if the file .git/shallow exists. The contents of this file are a bit sneaky: most of Git treats it in exactly the same way as .git/grafts. That is, each line in the shallow file contains a commit hash ID (and nothing else, vs grafts, where each line is followed by all the grafted parent IDs: since the line is empty, there are no parent IDs and the commit becomes a root commit). (Git can flag it internally as "not really a root", indicating that it has parents that simply have never been obtained. To be completely reliable, this would also require ensuring that no actual root commit IDs are ever stored in the file, and I am not sure if that is the case.)

You could compute a max depth of all references: starting with each reference, count graph depth from that tipmost commit down to a (possibly grafted) root. This would not, however, necessarily be the number passed to --depth (here or, later, with a --depth given to git fetch).

Suppose, for instance, that we clone a repository that has only two commits, while also using --depth 10. The deepest chain is either one or two commits long, since there are only two commits: one (real) root for certain, and one commit that might have the other as its parent, or might be another (real) root commit. If—this is the case I do not know the answer to—the .git/shallow file never contains real roots, it would be empty at this point and we would know that however long the longest chain is, the --depth argument must have been greater than that, but we would not know the actual number.

Suppose, on the other hand, we clone a 10-or-more-commit repository, with our --depth 10, and get a chain of 10 commits terminated by a fake-root-graft. Then we add two new commits to this 10-long chain, so that we have a 12-commit chain. The --depth is still 10, but counting chains, we find 12.

So, this shows two ways that a computed count could be too small or too large. In many circumstances, though, the computed count would work well. To get computed counts, use git for-each-ref to find each reference, and git rev-list --count --first-parent on each found reference. Whatever maximum you get is likely the depth number, or something close enough.

这篇关于如何知道git的浅层克隆的深度?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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