What does 'git commit' mean when it says &

问题:

EDIT:

See Danny Lin's git-store-meta as a proposed solution to the versioning-metadata problem described below. I have yet to test it as of 2015-05-13.

ORIGINAL QUESTION:

Do the create|delete mode ... lines in the git commit output (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 do with 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.

[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 is currently storing might prove useful to solve this problem.]

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 ~# 

回答1:

For more information about Git's mode, see this answer.

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 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.

回答2:

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

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.

回答3:

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).