def git_blob_hash(data):
if isinstance(data, str):
data = data.encode()
data = b'blob ' + str(len(data)).encode() + b'\0' + data
h = hashlib.sha1()
h.update(data)
return h.hexdigest()
git-hash-object () { # substitute when the `git` command is not available
local type=blob
[ "$1" = "-t" ] && shift && type=$1 && shift
# depending on eol/autocrlf settings, you may want to substitute CRLFs by LFs
# by using `perl -pe 's/\r$//g'` instead of `cat` in the next 2 commands
local size=$(cat $1 | wc -c | sed 's/ .*$//')
( echo -en "$type $size\0"; cat "$1" ) | sha1sum | sed 's/ .*$//'
}
6条答案
按热度按时间41zrol4v1#
Git在对象前面加上“blob”,然后是长度(作为一个人类可读的整数),最后是一个NUL字符
第一个月
来源:http://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html
llmtgqce2#
我只是对
@Leif Gruenwoldt
的答案进行了扩展,并详细介绍了@Leif Gruenwoldt
提供的reference中的内容**自己动手 *
git ls-tree HEAD
来识别blob的哈希值e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
GIT如何计算其提交哈希
字符串
文本
blob⎵
是一个常量前缀,\0
也是一个常量,是NULL
字符。<size_of_file>
和<contents_of_file>
因文件而异。请参阅:What is the file format of a git commit object?
这就是所有的乡亲!
但是等等!,您是否注意到
<filename>
不是用于散列计算的参数?如果两个文件的内容是相同的,而不管它们的创建日期和时间以及它们的名称如何,则它们可能具有相同的哈希值。这也是Git比其他版本控制系统更好地处理移动和重命名的原因之一。自己动手(分机)
filename
的空文件备注:
该链接没有提到如何对
tree
对象进行哈希处理。我不确定算法和参数,但根据我的观察,它可能会根据它包含的所有blobs
和trees
(可能是它们的散列)计算散列qkf9rpyu3#
一月一日
这是一种快速验证测试方法的方法:
字符串
输出量:
型
其中
sha1sum
位于GNU核心应用程序中。然后,它归结为理解每种对象类型的格式。我们已经讨论了
blob
这个小问题,下面是其他问题:hk8txs484#
我在Python 3中的一些单元测试中需要它,所以我想我应该把它留在这里。
字符串
我在所有地方都坚持使用
\n
行尾,但在某些情况下,Git可能会在计算这个哈希值之前更改行尾,因此您可能也需要使用.replace('\r\n', '\n')
。e7arh2l65#
基于Leif Gruenwoldt的答案,下面是
git hash-object
的shell函数替代:字符串
试验项目:
型
jvlzgdj96#
这是一个用于二进制哈希计算的python3版本(上面的例子是针对文本的)
为了便于阅读,请将此代码放在您自己的def中。另请注意,代码是一个片段,而不是完整的脚本。给你灵感。
字符串