为什么Git只散列文件的内容？

从中，计算Git中文件的哈希值

    Commit Hash (SHA1) = SHA1("blob " + <size_of_file> + "\0" + <contents_of_file>)

但是为什么Git从散列中排除文件名呢？它如何区分empty1.txt和empty2.txt

如果我将empty1.txt的名称更改为empty2.txt，那么当我调用Git status时，Git如何跟踪该更改

但是为什么Git从散列中排除文件名呢？它如何区分empty1.txt和empty2.txt

因为Git管理内容（如果两个文件的内容相同，那么它们的SHA1也会相同）

文件名由管理，其中列出了给定文件夹中的文件

---

Git通过树结构管理工作目录。在该树结构中，文件名以字典的方式映射到SHA-1 blob。所以树维护文件名和SHA-1之间的关系，而不是blob本身。这个树结构是显式对象（例如HashMap）吗？这个树结构和Git的结构相同吗？提交、树、blob、标记？我不知道“显式”对象是什么意思，但它确实存储在某个地方。是的，它是Git使用的四个对象之一。啊，这很有意义——所以当调用status时，Git只是比较提交树和其父级树，对吗？我不确定这一点……我对Git实现的了解相当有限。我只是想指出，blob SHA-1不是唯一用来标识文件的东西，这些blob是树结构的一部分。因此，如果我理解正确，Git会创建一个包含索引中列出的对象的树。对象的类型（树、blob）是否与SHA-1一起存储在该文件中？然后，Git如何使用这个索引/树来检测哪些文件已被修改、未跟踪或删除？索引本身是一个未与提交关联的树吗？当我打开存储库的索引时，我注意到它已被序列化。@SlackOverflow该类型是SHA1:Edit:的一部分，似乎表明情况并非如此。不过，我还是想知道索引如何在不成为对象的情况下进行快速比较。@SlackOverflow git状态最近有所改善：

    100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       empty1.txt
    100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       empty2.txt

$ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614
040000 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579      bak
100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt