在git中，长和短的哈希之间有什么区别？ [英] In git, what is the difference between long and short hashes?

问题描述

这里是long git hash：

提交c26cf8af130955c5c67cfea96f9532680b963628

合并：8654907 37c2a4f

作者：nicolas

日期：Wed Apr 26 13:28:22 2017 -0400

这里是简短的一个

解决方案

为了详细说明为什么短散列很有用，以及为什么你通常不需要长散列，它必须与Git如何存储事物有关。 p>

c26cf8af130955c5c67cfea96f9532680b963628 将存储在两个地方之一中。它可以位于 .git / objects / c2 / 6cf8af130955c5c67cfea96f9532680b963628 文件中。请注意，前两个字符 c2 组成一个目录，其余的是文件名。由于许多文件系统在一个目录中的文件太多时效果不佳，这可以防止任何一个目录中包含太多文件，并保持这个小目录数据库的有效性。

<使用短散列， c26cf8a ，git可以做相当于 .git / objects / c2 / 6cf8a * 这可能是一个单一的文件。由于对象被细分为子目录，所以没有太多的文件名需要查看来检查是否有多个匹配。

c26cf8a 包含足够的可能性，16 ^ 7或2 ^ 28或268,435,456，这是非常不可能的另一个提交将共享该前缀。

基本上，Git使用文件系统本身就是一个简单的键/值存储，它可以查找部分键而不必扫描整个键列表。

---

<这是存储对象的一种方法。越来越多的Git将其对象存储在包文件中。这是一种非常有效的方式来存储文件之间的更改。有时，你的Git仓库将检查 .git / objects 中的内容，并将差异存储在 .git / objects / pack / pack- < checksum> 。

这是一种二进制格式，我不打算在这里介绍它，但我不明白无论如何。 ：）

Here is the long git hash:

commit c26cf8af130955c5c67cfea96f9532680b963628

Merge: 8654907 37c2a4f

Author: nicolas

Date: Wed Apr 26 13:28:22 2017 -0400

Here is the short one

解决方案

To elaborate a bit more about why the short hash is useful, and why you often don't need the long hash, it has to do with how Git stores things.

c26cf8af130955c5c67cfea96f9532680b963628 will be stored in one of two places. It could be in the file .git/objects/c2/6cf8af130955c5c67cfea96f9532680b963628. Note that the first two characters, c2, make up a directory and the rest is the filename. Since many filesystems don't perform well when there's too many files in one directory, this prevents any one directory from having too many files in it and keeps this little directory database efficient.

With just the short hash, c26cf8a, git can do the equivalent of .git/objects/c2/6cf8a* and that's likely to be a single file. Since the objects are subdivided into subdirectories, there's not too many filenames to look through to check if there's more than one match.

c26cf8a alone contains enough possibilities, 16^7 or 2^28 or 268,435,456 that it's very unlikely another commit will share that prefix.

Basically, Git uses the filesystem itself as a simple key/value store, and it can look up partial keys without having to scan the whole list of keys.

---

That's one way to store objects. More and more, Git stores its objects in packfiles. It's a very efficient way to store just the changes between files. From time to time, your Git repository will examine what's in .git/objects and store just the differences in .git/objects/pack/pack-<checksum>.

That's a binary format, I'm not going to get into it here, and I don't understand it myself anyway. :)

这篇关于在git中，长和短的哈希之间有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！