43

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 per 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?"? 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 ~#
Johnny Utahh
  • 2,109
  • 2
  • 23
  • 33
  • 1
    `Mode`'s `last three number` is the `file permissions` for different user groups. And the `first three` is about the `file type`, not very clear about this. You can try to think like this: create a file named `dummy-file-will-be-removed` whose `mode is 100644`. ;) – Kjuly Dec 15 '11 at 16:04

3 Answers3

26

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.

Community
  • 1
  • 1
Dan Cruz
  • 14,336
  • 6
  • 39
  • 64
  • +1 for [this answer](http://stackoverflow.com/a/8347325/605356), thx. fwiw, am trying to extend git capabilities with **optional** control for metadata in potentially OS/filesystem specific fashion. Proper automated system deployment is headache without good file metadata control for just the basics that are common across many/most POSIX/unix/linx/MacOS filesystems. (Read: I'm not auto-deploying on Windows.) More details at my [question here](http://superuser.com/questions/367729/how-to-reuse-extend-etckeepers-metadata-engine-for-git-control-of-non-etc-file). – Johnny Utahh Dec 15 '11 at 16:16
  • Edits to original question to address above. Alas, per the above answer, have now (presumably) discovered the limits of git's `index-format.txt`, which is [pretty limited](http://stackoverflow.com/a/8347325/605356). However, said answer does describe a group-writable file, which is new news, and useful...assuming it works. – Johnny Utahh Dec 15 '11 at 16:36
  • @JohnnyUtahh Your [SuperUser question](http://superuser.com/questions/367729/how-to-reuse-extend-etckeepers-metadata-engine-for-git-control-of-non-etc-file) is a good, researched question; one whose solution I would be interested in. I'm not aware of any Git tools or extensions to allow versioning of file metadata. – Dan Cruz Dec 15 '11 at 16:43
  • Thx. Have pretty much exhausted this (git metadata) domain with several queries. Waiting to see if any new efforts/projects arise per [this conversation](http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-tp6251248p7092383.html). – Johnny Utahh Dec 15 '11 at 16:49
  • @'Dan Cruz' check out [Danny Lin's proposed new tool](http://superuser.com/a/904053/98033) to solve the versioning-metadata problem. I've yet to test it. – Johnny Utahh May 13 '15 at 17:27
10

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.

patthoyts
  • 29,437
  • 2
  • 54
  • 84
  • 3
    Should be worth mentioning that this `644` is *not* necessarily the actual unix permissions of the given file: files with `664` and `600` permissions will be stored in git as `644` – MestreLion Dec 20 '12 at 07:47
  • 2
    -- not that you are wrong. I just tried using git 1.8.0.1 on Linux and indeed the 0600 file I added shows up as 0644 in git tree. This might be a bug or it might be by design. – patthoyts Dec 20 '12 at 12:40
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).

fge
  • 110,072
  • 26
  • 223
  • 312