git：悬垂的斑点
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9955713/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
git: dangling blobs
提问by wadesworld
I recently ran git fsck --lost-foundon my repository.
我最近git fsck --lost-found在我的存储库上运行。
I expected to see a couple dangling commits, where I had reset HEAD.
我希望看到一些悬空的提交，我已经重置了HEAD。
However, I was surprised to see likely over several thousand dangling blob messages.
然而，我很惊讶地看到可能有超过数千条悬垂的 blob 消息。
I don't believe anything is wrong with my repository, but I'm curious as to what causes these dangling blobs? There's only two people working on the repository, and we haven't done anything out of the ordinary.
我不相信我的存储库有任何问题，但我很好奇是什么导致了这些悬空的斑点？只有两个人在存储库上工作，我们没有做任何不寻常的事情。
I wouldn't think they were created by an older version of a file being replaced by a new one, since git would need to hold onto both blobs so it can display history.
我不认为它们是由旧版本的文件替换为新文件创建的，因为 git 需要保留两个 blob，以便它可以显示历史记录。
Come to think of it, at one point we did add a VERY large directory (thousands of files) to the project by mistake and then remove it. Might this be the source of all the dangling blobs?
想想看，有一次我们确实错误地向项目添加了一个非常大的目录（数千个文件），然后将其删除。这可能是所有悬垂斑点的来源吗？
Just looking for insight into this mystery.
只是想深入了解这个谜团。
采纳答案by Waynn Lue
Last time I looked at this I stumbled across this thread, specifically this part:
上次我看这个时，我偶然发现了这个线程，特别是这部分：
You can also end up with dangling objects in packs. When that pack is repacked, those objects will be loosened, and then eventually expired under the rule mentioned above. However, I believe gc will not always repack old packs; it will make new packs until you have a lot of packs, and then combine them all (at least that is what "gc --auto" will do; I don't recall whether just "git gc" follows the same rule).
您也可能最终会在包中悬挂物体。当该包被重新打包时，这些对象将被松开，然后最终根据上述规则过期。但是，我相信 gc 不会总是重新打包旧包；它会制作新的包，直到你有很多包，然后将它们全部组合起来（至少“gc --auto”会这样做；我不记得是否只是“git gc”遵循相同的规则）。
So it's normal behavior, and does get collected eventually, I believe.
所以这是正常行为，我相信最终会被收集。
edit: Per Daniel, you can immediately collect it by running
编辑：Per Daniel，您可以通过运行立即收集它
git gc --prune="0 days"
回答by Daniel
I was really impatient and used:
我真的很不耐烦并使用：
git gc --prune="0 days"
回答by knittl
Whenever you adda file to the index, the content of that file are added to Git's object database as a blob. When you then reset/rm --cachedthat file, the blobs will still exist (they will be garbage collected the next time you run gc)
每当您add将文件添加到索引时，该文件的内容都会作为 blob 添加到 Git 的对象数据库中。当您reset/rm --cached该文件时，blob 仍然存在（下次运行时它们将被垃圾收集gc）
However, when those files are part of a commit and you decide later to resethistory, then the old commits are still reachable from Git's reflog and will only be garbage collected after a period of time (usually a month, iirc). Those objects should not show up as dangling though, since they are still referenced from the reflog.
但是，当这些文件是提交的一部分并且您决定稍后写入reset历史记录时，旧提交仍然可以从 Git 的 reflog 访问，并且只会在一段时间（通常是一个月，iirc）后被垃圾收集。不过，这些对象不应该显示为悬空，因为它们仍然从 reflog 中引用。
