当git commit在stdout上显示“create mode…”时，它的意思是什么？

Question

编辑：

请参考Danny Lin的git-store-meta作为下面所述版本控制元数据问题的一种解决方案。截至2015年5月13日，我还没有测试过它。

原始问题：

git commit输出中的create|delete mode ...行表示某种元数据控制吗？（和/或者，这些行在一般情况下表示什么？）这些似乎是类Unix文件权限代码/表示，尽管我不确定-确切的映射是什么，但更大的问题是：git是否使用这些代码/设置/值？ git是否试图利用这些保存的代码以任何方式来证明有助于解决metadata问题，如我的超级用户问题"如何重用/扩展etckeeper的元数据引擎，以使其对非/etc文件系统进行git控制，或者通过本机方式扩展git具有此功能？"？ 我知道git不能控制所有文件系统元数据。

[Git显然已经控制了文件的“可执行属性/权限”（对大多数操作系统都是可移植的）以及一些其他内容，例如文件系统链接。 我正在寻找更多Unix/Linux/BSD/DarwinMacOSX特定的控制机制，用于更多/所有元数据，即所有权限和用户/组所有权。 ACL和其他元数据控制是可选的。试图看看git目前存储的东西是否可能有助于解决这个问题。

root@node1 Dec 15 09:40:45 ~/.../sandbox-1# git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   README
#   new file:   dummy-file-will-be-removed
#   deleted:    ownerfile
#
root@node1 Dec 15 09:40:45 ~/.../sandbox-1# git commit -m "testing git"
[master c5b0201] testing git
 2 files changed, 1 insertions(+), 2 deletions(-)
 create mode 100644 dummy-file-will-be-removed
 delete mode 100644 ownerfile
root@node1 Dec 15 09:41:55 ~/.../sandbox-1# 
[...]
root@node1 Dec 15 11:33:11 ~# git --version
git version 1.7.4.1
root@node1 Dec 15 11:33:14 ~# 

- Johnny Utahh

---

Mode的最后三个数字是不同用户组的文件权限，而前三个数字则是关于文件类型的，这一点不是很清楚。你可以尝试这样想：创建一个名为dummy-file-will-be-removed的文件，其模式为100644。 ;) - Kjuly

Answer 1

关于Git模式的详细信息，请参见此答案。

Git存储文件元数据的能力受到了一些限制，只能存储一些基本的文件系统更改信息以便Git跟踪源代码管理中的相关更改，例如文件是否已修改以及文件是常规文件还是可执行文件。

Git没有尝试实现任何文件系统的概念，而是将文件系统例程留给实际的文件系统实现。这样做很有意义，可以使Git在运行在Linux、MacOS、Windows等操作系统上的FAT32、NTFS、EXT3、XFS、NFS等不同文件系统上同样工作。

- Go Dan

---

+1 给这个答案，谢谢。顺便说一下，我正在尝试通过可选的方式控制元数据，以便在可能的操作系统/文件系统特定方式下扩展git功能。对于许多/大多数POSIX/unix/linx/MacOS文件系统中通用的基本内容，适当的自动化系统部署是一个头疼问题，如果没有良好的文件元数据控制。(读者：我不会在Windows上自动部署。)更多细节请参见我的问题。 - Johnny Utahh

根据上面的回答，对原问题进行了编辑以解决问题。不幸的是，现在（可能）已经发现了git的index-format.txt的限制，它相当有限。然而，该回答确实描述了一个组可写文件，这是新的消息，并且很有用...假设它能正常工作。 - Johnny Utahh

@JohnnyUtahh，你的SuperUser问题是一个很好的、经过研究的问题；我对它的解决方案很感兴趣。我不知道是否有任何Git工具或扩展可以允许对文件元数据进行版本控制。 - Go Dan

谢谢。我已经用几个查询耗尽了这个（git元数据）领域。正在等待看是否会有任何新的努力/项目出现，根据此对话。 - Johnny Utahh

@'Dan Cruz' 请查看Danny Lin提出的新工具来解决版本控制元数据问题。我还没有测试过它。 - Johnny Utahh

Answer 2

这些是以类Unix权限值的方式表示的文件权限。它们以八进制形式打印，并代表读取、写入和执行的3位二进制位组合。如果您查看git中的树对象（例如：git ls-tree HEAD），您可以看到git记录有关目录内容的所有信息。该树包含具有权限位的树和blob。

C:\project>git ls-tree HEAD
100644 blob 66f3f25c8ca9ae73b99669aca6ba5ecfa4703b2b    .gitignore
100644 blob 60b88ac20b8b7cccdcd856e65415a9eb9495b63a    Makefile
040000 tree e1d9381e4d12effea7e33f8d7e2b16e372f67b51    demos
100644 blob a60e08eeb9f75160ae2bf6a9feeff3c1c75bfc1d    doxygen.cfg

6 表示可读写，4 表示只读。

- patthoyts

---

值得一提的是，这个 644 并不一定是给定文件的实际 Unix 权限：拥有 664 和 600 权限的文件将以 644 的形式存储在 Git 中。 - MestreLion

需要引用来源 -- 并不是说你错了。我刚试着在Linux上使用git 1.8.0.1，确实我添加的0600文件在git树中显示为0644。这可能是一个bug，也可能是设计如此。 - patthoyts

@patthoyts：这在2022年11月的git版本2.38.1中仍然是正确的（我在macOS上尝试过）。 - nishanthshanmugham

根据https://git.wiki.kernel.org/index.php/ContentLimitations，这是有意设计的。引用该页面的话：“按设计，git无法跟踪文件系统的其他方面，包括：文件模式（除了“可执行”位和符号链接）”。 - nishanthshanmugham

Answer 3

不，git不会存储完整的元数据。它只会存储文件类型（仅限于常规文件、目录和符号链接），以及文件是否可执行（默认情况下，目录是可执行的）。请注意，HTML标签已被保留，请勿删除。

- fge