编辑:
请参阅Danny Lin's git-store-meta作为下面描述的版本控制元数据问题的建议解决方案。我还没有在2015-05-13测试它。
原始问题:
create|delete mode ...
输出中的git commit
行(下面的示例)是否代表某种元数据控制? (和/或,这些线通常代表什么?)这些似乎是类似unix的文件 - 权限代码/表示,虽然我不确定 - 确切地说 - 映射,但更大的问题是:如果有什么做的话使用这些代码/设置/值git 执行? git是否试图以任何方式利用这些保存的代码来证明有助于解决元数据问题我的superuser.com问题[“如何重用/扩展etckeeper的元数据引擎,用于git控制非/ etc文件系统,或者使用所述功能本地扩展git ?“(https://superuser.com/questions/367729/how-to-reuse-extend- etckeepers-metadata-engine-for-git-control-of-etc-file)?我知道git不能控制所有文件系统元数据。
[Git显然已经控制了文件的“可执行属性/ perm”(对大多数操作系统来说显然是可移植的)以及其他一些文件系统链接。我正在寻找更多/所有元数据的更多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 ~#
答案 0 :(得分:22)
有关Git模式的更多信息,请参阅this answer。
Git存储文件元数据的能力仅限于一个简单的信息子集,以允许Git跟踪一些基本的文件系统更改,从而允许Git跟踪源代码管理的相关更改;例如文件是否已被修改以及文件是常规文件还是可执行文件。
Git不会尝试实现文件系统的任何概念,而是将文件系统例程留给实际的文件系统实现。无论是在运行于Linux,MacOS,Windows等的FAT32,NTFS,EXT3,XFS,NFS等文件系统上,这都允许Git同等工作。
答案 1 :(得分:6)
这些是作为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表示只读。
答案 2 :(得分:3)
不,git不存储完整的元数据。它只存储文件的类型(并且它仅限于常规文件文件,目录和符号链接)以及文件是否可执行(当然,默认情况下是哪些目录)。