Come fa Git a sapere che il file è stato rinominato?

Question

Quale algoritmo utilizza Git per determinare che alcuni file sono stati rinominati?

Questo è, ciò che git status prodotto solo pochi minuti prima:

Informazioni contrassegnati con box giallo non è corretto. In realtà non c'era un tale tipo di rinominare. I file views/file/create.php e views/file/index.php sono stati veramente eliminati mezz'ora dopo un set completamente nuovo di due file: views/logo/create.php e views/logo/index.php.

Entrambi i set di file possono sembrare (a Git) abbastanza simili, ma il fatto rimane - questi non sono gli stessi file rinominati. Questa è una nuova serie completa di file, creati in diverse directory circa mezz'ora prima di eliminare il primo set di file.

Poiché le informazioni fornite da Git non sono corrette, vorrei nutrire la mia curiosità ed è per questo che sto chiedendo.

Answer 1

Da Wikipedia:

Rinomina vengono gestiti in modo implicito, piuttosto che in modo esplicito. Un reclamo comune con CVS è che utilizza il nome di un file per identificare la cronologia delle revisioni , quindi lo spostamento o la ridenominazione di un file non è possibile senza interrompendo la cronologia o rinominando la cronologia e quindi rendendo la cronologia rendendo imprecisa la cronologia. La maggior parte dei sistemi di controllo di revisione post-CVS risolve questo dando a un file un nome longevo unico (una sorta di numero inode ) che sopravvive alla ridenominazione. Git non registra tale identificatore e questo è rivendicato come un vantaggio. [34] [35] I codici sorgente a volte vengono divisi o uniti e semplicemente rinominati, [36] e registrando ciò come una semplice rinomina congelerebbe una descrizione imprecisa di di ciò che è accaduto nella storia (immutabile). Git affronta il problema con lo rilevando le rinomanze durante la navigazione nella cronologia delle istantanee anziché registrarlo quando si crea lo snapshot. [37] (Brevemente, dato un file nella revisione N, un file con lo stesso nome nella revisione N-1 è il suo antenato predefinito . Tuttavia, quando non c'è un file con nome simile nella revisione N-1, Git cerca un file che esisteva solo nella revisione N-1 ed è molto simile al nuovo file.) Tuttavia, richiede più lavoro ad alta intensità di CPU ogni volta che viene revisionata la cronologia e un numero di opzioni per regolare l'euristica. Questo meccanismo non sempre funziona ; a volte un file che viene rinominato con modifiche nello stesso commit viene letto come una cancellazione del vecchio file e la creazione di un nuovo file. Gli sviluppatori possono ovviare a questa limitazione inviando il nome e le modifiche separatamente.