Come dovrebbe comportarsi git quando due collegamenti a stesso file sono diversi?

Question

ho osservato il seguente comportamento durante il lavoro con la base di codice Perl (sul ramo maint-5.004):

bash-3.2$ git status | grep modified
#       modified:   configure
bash-3.2$ git reset --hard
HEAD is now at 9a4fb7e copy over bleads .gitignore
bash-3.2$ git status | grep modified
#       modified:   Configure
bash-3.2$ git reset --hard
HEAD is now at 9a4fb7e copy over bleads .gitignore
bash-3.2$ git status | grep modified
#       modified:   configure

Questo sta accadendo perché i due file condividono un inode (sono lo stesso file), ma sono diversi nell'indice git. La mia domanda è: come è potuto accadere? Se git sta rintracciando 2 collegamenti per lo stesso file, dovrebbe essere previsto per git bandiera come un errore quando uno di loro viene modificato solo? Si tratta di un errore di git bug o utente?

Aggiornamento:

Sembra che il problema non è con git, ma è legato a caso la sensibilità del filesystem (HFS +).

$ mkdir tmp
$ cd tmp
$ touch foo
$ ls -i foo Foo
10301082 Foo    10301082 foo

Penso che forse che OS X ha bisogno di riconsiderare come una piattaforma utile per lo sviluppo, in quanto questo comportamento è assurdo.

Answer 1

sistemi di controllo del codice sorgente in genere hanno problemi di tracciamento collegamenti fisici. Si dovrebbe aver fatto uno di loro un collegamento simbolico e aggiungere il link simbolico a git e che avrebbe funzionato bene. Git in grado di gestire bene i collegamenti simbolici.

A meno che non si sarebbe in qualche modo puntare a un sistema di controllo del codice sorgente che un file si aggiunge al repository è un collegamento reale, non ha modo di conoscere e di certo non andrà a confronto inode di tutti i file su tutti i aggiungere solo per scoprire se questo è il caso.

Anche i sistemi che consentono collegamenti fisici cercano di evitare di creare a tutti i costi, dal momento che il numero di problemi creati dai collegamenti fisici è abbastanza alto e tutti i bug e le incongruenze risultanti sono molto difficili da rintracciare. Dopo un po 'e qualche rinomina e si muove su uno dei collegamenti, due squadre diverse potrebbero ciascuna un pezzo del collegamento reale in una parte della struttura di origine loro e una lotta per il contenuto dell'albero versione dell'oggetto deriva con nessuno di essere troppo saggio sul perché senza le modifiche fatte alla vostra parte di un albero di origine contenuto di file sta cambiando. E 'meglio usare i link simbolici.

Answer 2

Sembra come un insetto git per me. Se ho capito bene hai fatto un collegamento reale da Configura per configurare e Git è correttamente vederle come entità separate, ma quando uno cambia dovrebbero entrambi variazione dell'indice git.

Sono corretto nella valutazione che questi sono un collegamento fisico?

Answer 3

Non sono sicuro git traccia in realtà inode, probabilmente solo si occupa con i nomi dei file. Date un'occhiata a questa esecuzione del campione, per esempio:

$ mkdir so.question
$ cd so.question/
$ git init
Initialized empty Git repository in /tmp/so.question/.git/
$ echo "test" > a
$ ln a b
$ ls -i
539367 a  539367 b
$ git add a b
$ git commit -m"One"
[master (root-commit) 897cdea] One
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 a
 create mode 100644 b
$ echo "test" >> a
$ git add a
$ git commit -m"Two"
[master bbcba39] Two
 1 files changed, 1 insertions(+), 0 deletions(-)
$ ls -i
539367 a  539367 b
$ git reset --hard
HEAD is now at bbcba39 Two
$ ls -i
539367 a  539389 b

Si noti che se registro un commit con modifiche solo uno dei file, Git registra una modifica al file a e assume b non è stato cambiato (come ci si aspetta). Per quanto riguarda il git è interessato, l'altro file non è stato modificato. Se in seguito si fa un reset git, gli inode di file non sarà più lo stesso come si differenziano.

Non ero in grado di riprodurre il comportamento da te segnalato (modifiche di segnalazione git status destra dopo un hard reset) e mi chiedo se questo è ancora possibile (se non per un bug). Puoi venire su con un piccolo esempio che mostra il comportamento si osserva?