“git commit”在标准输出上显示“创建模式...”是什么意思？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8521938/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What does 'git commit' mean when it says 'create mode ...' on stdout?
提问by Johnny Utahh
EDIT:
编辑：
See Danny Lin's git-store-metaas a proposed solution to the versioning-metadata problem described below. I have yet to test it as of 2015-05-13.
请参阅Danny Lin 的 git-store-meta作为以下描述的版本控制元数据问题的建议解决方案。截至 2015 年 5 月 13 日，我尚未对其进行测试。
ORIGINAL QUESTION:
原问题：
Do the create|delete mode ...lines in the git commitoutput (example below) represent some sort of metadata control? (And/or, what do these lines represent in general?) These appear to be unix-like file-permission codes/representations, although I'm not sure -exactly- the mapping, but the bigger question is: what if anything does git dowith these codes/settings/values? Does git attempt to leverage these saved codes in any way to prove helpful to solve metadata problems my superuser.com question ["How to reuse/extend etckeeper's metadata engine for git control of non-/etc filesystems, or extend git natively with said capability?"](https://superuser.com/questions/367729/how-to-reuse-extend-etckeepers-metadata-engine-for-git-control-of-non-etc-file)? I'm aware that git doesn't control all filesystem metadata.
输出中的create|delete mode ...行git commit（下面的示例）是否表示某种元数据控制？（和/或，这些行一般代表什么？）这些似乎是类似 Unix 的文件权限代码/表示，虽然我不确定 - 确切地说 - 映射，但更大的问题是：如果有的话怎么办混帐做了与这些代码/设置/值？git 是否尝试以任何方式利用这些保存的代码来证明有助于解决我的 superuser.com 问题的元数据问题?"]( https://superuser.com/questions/367729/how-to-reuse-extend-etckeepers-metadata-engine-for-git-control-of-non-etc-file)？我知道 git 不控制所有文件系统元数据。
[Git does apparently, already control the "executeable attribute/perm" of a file (apparently portable for most OSes) and some other things like filesystem links. I'm seeking a more Unix/Linux/BSD/DarwinMacOSX-specific control mechanism for more/all metadata, namely all permissions and user/group ownership. ACLs and other metadata control optional. Trying to see if the stuff git iscurrently storing might prove useful to solve this problem.]
[Git 显然已经控制了文件的“可执行属性/perm”（对于大多数操作系统显然是可移植的）和其他一些东西，比如文件系统链接。我正在为更多/所有元数据寻求更多 Unix/Linux/BSD/DarwinMacOSX 特定的控制机制，即所有权限和用户/组所有权。ACL 和其他元数据控制可选。想看看是否混帐东西是目前存储可能证明是有用的，以解决这一问题。]
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 ~#
采纳答案by Dan Cruz
For more information about Git's mode, see this answer.
有关 Git 模式的更多信息，请参阅此答案。
Git's ability to store file metadata is limited to a simple subset of information to allow Git to track some basic file system changes allowing Git to track relevant changes for source code management; such as whether a file has been modified and whether a file is a regular file or an executable file.
Git 存储文件元数据的能力仅限于一个简单的信息子集，以允许 Git 跟踪一些基本的文件系统更改，从而允许 Git 跟踪源代码管理的相关更改；例如文件是否被修改，文件是普通文件还是可执行文件。
Git does not try to implement any notion of a file system, leaving file system routines to an actual file system implementation. This makes good sense to allow Git to work equally whether on a FAT32, NTFS, EXT3, XFS, NFS, etc. file system running on Linux, MacOS, Windows, etc.
Git 不会尝试实现任何文件系统的概念，而是将文件系统例程留给实际的文件系统实现。这对于允许 Git 在 Linux、MacOS、Windows 等上运行的 FAT32、NTFS、EXT3、XFS、NFS 等文件系统上同等工作是很有意义的。
回答by patthoyts
These are the file permissions as unix-style permissions values. They're printed in octal and represent clusters of 3 bits for read, write and execute. If you look at a tree object in git (eg: git ls-tree HEAD) you can see everything git records about the contents of a directory. That is tree contains trees and blobs with the permissions bits
这些是作为 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 means read-write, 4 is readonly.
6 表示可读写，4 表示只读。
回答by fge
No, git does not store full metadata. It only stores the type of the file (and it is limited to regular filesfiles, directories and symlinks) and whether the file is executable (which directories are by default, of course).
不，git 不存储完整的元数据。它只存储文件的类型（并且仅限于常规文件、目录和符号链接）以及文件是否可执行（当然，默认情况下是哪些目录）。
