Cosa significa 'git commit' quando dice 'create mode ...' su stdout?

Question

MODIFICA:

Vedere Danny Lin's git-store-meta come una soluzione proposta per il problema dei metadati di versioni descritto di seguito. Devo ancora provarlo dal 2015-05-13.

domanda iniziale:

fare le create|delete mode ... linee nel git commit uscita (esempio qui sotto) rappresentano una sorta di controllo metadati? (E/o, che cosa rappresentano queste righe in generale?) Questi sembrano essere codici/rappresentazioni di permessi file unix-like, anche se non sono sicuro -exactly- la mappatura, ma la domanda più grande è: cosa succederebbe se qualcosa git do con questi codici/impostazioni/valori? Git tenta di sfruttare questi codici salvati in qualsiasi modo per dimostrarsi utile per risolvere i problemi dei metadati la mia domanda superuser.com ["Come riutilizzare/estendere il motore di metadati di etckeeper per il controllo git di filesystem non/etc, o estendere git nativamente con dette funzionalità ? "] (https://superuser.com/questions/367729/how-to-reuse-extend- etckeepers-metadata-engine-per-git-control-of-non-etc-file)? Sono consapevole che git non controlla tutti i metadati del filesystem.

[Git a quanto pare, già controlla "l'attributo eseguibile/perm" di un file (apparentemente portatile per la maggior parte dei sistemi operativi) e alcune altre cose come i collegamenti al filesystem. Sto cercando un meccanismo di controllo più specifico per Unix/Linux/BSD/DarwinMacOSX per più/tutti i metadati, ovvero tutte le autorizzazioni e la proprietà di utenti/gruppi. ACL e altri controlli dei metadati facoltativi. Cercando di vedere se la roba git è attualmente memorizzando potrebbe rivelarsi utile per risolvere questo problema.]

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

Answer 1

Per ulteriori informazioni sulla modalità di Git, vedere this answer.

La capacità di Git di archiviare i metadati dei file è limitata a un semplice sottoinsieme di informazioni per consentire a Git di tenere traccia delle modifiche di base del file system consentendo a Git di tenere traccia delle modifiche rilevanti per la gestione del codice sorgente; ad esempio se un file è stato modificato e se un file è un file normale o un file eseguibile.

Git non tenta di implementare alcuna nozione di un file system, lasciando le routine del file system a un'implementazione di file system effettiva. Questo ha senso consentire a Git di funzionare allo stesso modo su un file system FAT32, NTFS, EXT3, XFS, NFS, ecc. Su Linux, MacOS, Windows, ecc.

Answer 2

No, git non memorizza i metadati completi. Memorizza solo il tipo di file (ed è limitato a file di file, directory e collegamenti simbolici) e se il file è eseguibile (quali directory sono, di default, ovviamente).

Answer 3

Questi sono i permessi dei file come valori di permessi stile unix. Sono stampati in ottale e rappresentano gruppi di 3 bit per lettura, scrittura ed esecuzione. Se guardi un oggetto ad albero in git (es .: git ls-tree HEAD) puoi vedere tutto git records sul contenuto di una directory. Cioè albero alberi e macchie con le autorizzazioni bit

C:\project>git ls-tree HEAD 
100644 blob 66f3f25c8ca9ae73b99669aca6ba5ecfa4703b2b .gitignore 
100644 blob 60b88ac20b8b7cccdcd856e65415a9eb9495b63a Makefile 
040000 tree e1d9381e4d12effea7e33f8d7e2b16e372f67b51 demos 
100644 blob a60e08eeb9f75160ae2bf6a9feeff3c1c75bfc1d doxygen.cfg 

6 mezzi di lettura-scrittura, 4 'in sola lettura.