Que signifie «git commit» quand il dit «create mode ...» sur stdout?
ÉDITER:
Voir git-store-meta de Danny Lin comme solution proposée au problème de versionnage des métadonnées décrit ci-dessous. Je dois encore le tester en date du 13/05/2015.
QUESTION ORIGINALE:
Faites le create|delete mode ... lignes dans le git commit la sortie (exemple ci-dessous) représente une sorte de contrôle des métadonnées? (Et/ou, que représentent ces lignes en général?) Il semble s'agir de codes/représentations d'autorisation de fichier de type Unix, bien que je ne sois pas sûr (exactement) du mappage, mais la plus grande question est: que faire si quelque chose git faire avec ces codes/paramètres/valeurs? Git essaie-t-il de tirer parti de ces codes enregistrés de quelque manière que ce soit pour se révéler utile pour résoudre les problèmes de métadonnées ma question superuser.com ? "] ( https://superuser.com/questions/367729/how-to-reuse-extend- etckeepers-metadata-engine-for-git-control-of-non-etc-file )? Je suis conscient que git ne contrôle pas toutes les métadonnées du système de fichiers.
[Git contrôle apparemment, déjà "l'attribut exécutable/perm" d'un fichier (apparemment portable pour la plupart des OS) et d'autres choses comme les liens du système de fichiers. Je cherche un mécanisme de contrôle plus spécifique Unix/Linux/BSD/DarwinMacOSX pour plus/toutes les métadonnées, à savoir toutes les autorisations et la propriété des utilisateurs/groupes. ACL et autres contrôles de métadonnées facultatifs. Essayer de voir si le truc git est actuellement stocké pourrait s'avérer utile pour résoudre ce problème.]
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 ~#
Pour plus d'informations sur le mode de Git, voir cette réponse .
La capacité de Git à stocker des métadonnées de fichier est limitée à un simple sous-ensemble d'informations pour permettre à Git de suivre certaines modifications de base du système de fichiers, permettant à Git de suivre les modifications pertinentes pour la gestion du code source; comme si un fichier a été modifié et si un fichier est un fichier normal ou un fichier exécutable.
Git n'essaie pas d'implémenter une quelconque notion de système de fichiers, laissant les routines de système de fichiers à une implémentation réelle du système de fichiers. Cela a du bon sens pour permettre à Git de fonctionner également, que ce soit sur un système de fichiers FAT32, NTFS, EXT3, XFS, NFS, etc. fonctionnant sous Linux, MacOS, Windows, etc.
Ce sont les autorisations de fichier en tant que valeurs d'autorisations de style Unix. Ils sont imprimés en octal et représentent des grappes de 3 bits pour la lecture, l'écriture et l'exécution. Si vous regardez un objet arbre dans git (par exemple: git ls-tree HEAD) vous pouvez voir tout ce que git enregistre sur le contenu d'un répertoire. C'est-à-dire que l'arbre contient des arbres et des blobs avec les bits d'autorisation
C:\project>git ls-tree HEAD
100644 blob 66f3f25c8ca9ae73b99669aca6ba5ecfa4703b2b .gitignore
100644 blob 60b88ac20b8b7cccdcd856e65415a9eb9495b63a Makefile
040000 tree e1d9381e4d12effea7e33f8d7e2b16e372f67b51 demos
100644 blob a60e08eeb9f75160ae2bf6a9feeff3c1c75bfc1d doxygen.cfg
6 signifie lecture-écriture, 4 est en lecture seule.
Non, git ne stocke pas les métadonnées complètes. Il ne stocke que le type du fichier (et il est limité aux fichiers, répertoires et liens symboliques normaux) et indique si le fichier est exécutable (quels répertoires sont par défaut, bien sûr).