问题描述
如果不运行 git prune
或 git gc
,git push
会上传任何未引用的对象吗?
想象一下这些提交历史:
A
在提交 C 中添加了一个新文件,并从提交 D 中删除了该文件。现在 git rebase --onto B D
将导致:
A
并且该文件仍在 .git/objects 中,因为它被两个分离的提交 C 和 D 引用。现在这两个事件中发生了什么:
-
将请求拉到远程分叉的主要上游。如果 1 的答案是肯定的,如果 C 和 D 从未与上游合并,该文件是否会合并到上游?
编辑:这个问题补充了此处讨论的案例HTTP Requests
解决方法
当您推送一个分支时,只有当前在该分支上的提交(即可从分支提示访问)被传输到远程。
,一般来说,git push
不会推送任何未引用的对象。
可能有特定的情况/优化可能会这样做,因为从来没有任何明确的承诺。但实际上并没有。
请注意,在您 rebase 之后,local 存储库有一个新的(不同的哈希 ID)提交 E'
:
C--D--E [reflog / ORIG_HEAD access only]
/
...--A--B
\
E' <-- somebranch (HEAD)
当您对其他某个 Git 运行 git push <othergit> somebranch
时,另一个 Git 将其分支提示提交哈希 ID 提供给您的 Git,而您的 Git 将提交 E'
的哈希 ID 提供给它们。他们显然还没有 E'
,因为你是自己做的,所以他们说他们想要(或没有),你的 Git 将 B
呈现给他们;如果他们没有那个,他们也会接受那个提交,如果需要,也会接受 A
,依此类推。
在某些时候,您的 Git 达到了他们确实拥有的某些提交,或者用完了要发送的提交哈希 ID。现在,您的两个 Git 就要发送的内容达成一致,并且作为这些协商的结果,您的 Git 知道他们已经提交哪些,以及哪些树和 blob 对象 他们也有(暗示他们有,例如,提交 A
以及所有更早的提交)。
你的 Git 现在——通常是1——准备了一个所谓的瘦包。这是您看到“计数对象”和“压缩对象”内容的地方。瘦包仅包含他们重建您发送的提交所需的那些对象:例如,在我们的特定示例中,提交 E'
和 B
。这包括它们没有的树和 blob 对象——提交 A
的存在并不暗示它们——但不包括它们确实拥有的树和 blob 对象。
这就是使包成为“瘦”包的原因:允许对丢失的对象进行增量压缩。假设提交 A
有一些文件由 10 兆字节的 blob 对象表示,提交 B
和/或 E'
有一些文件不是 100% 相同,但共享 99%那个 10 兆字节的对象。瘦包的新对象可以进行增量压缩,说从对象 _____ 中取出 9.9 MB(用哈希 ID 填充空白)并添加剩余的 100 kB。普通包必须包含这个“基础对象”,但瘦包不需要。
接收 Git 必须:
- 拿走来的薄包
- 检查传入的提交,并决定是否接受它们
- 如果它们被接受,“修复”薄包或将对象转换为松散(未打包)的对象。
接收方 Git 现在拥有新提交所需的所有对象,可以是松散的对象,也可以是新的固定的、不再精简的包。假设是后者,这个不再精简的包存储在该存储库中,因此新对象(可能还有一些从其他包中检索到的对象,如果需要)现在都在该存储库中,在这个现在常规的包中。>
(在某些时候,重新打包包装会变得有利可图。这部分变得相当复杂。)
1这取决于你的 Git 和他们的 Git 之间使用的协议。另一种选择是一次上传一个对象,这在通过网络发送的字节数方面往往非常浪费,因此人们现在通常不使用旧协议。