Comment devrait se comporter git lorsque deux liens vers un même fichier sont différents?

Question

J'observé le comportement suivant tout en travaillant avec la base de code Perl (sur la branche 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 

Cela se produit parce que les deux fichiers partagent un inode (ils sont le même fichier), mais ils sont différent dans l'index git. Ma question est la suivante: comment cela s'est-il passé? Si git suit 2 liens vers le même fichier, devrait-on s'attendre à ce qu'il marque une erreur quand un seul d'entre eux est modifié? Est-ce un bug git ou une erreur de l'utilisateur?

Mise à jour:

Il semble que la question est pas git, mais est liée à la casse du système de fichiers (HFS +).

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

Je pense peut-être que OS X doit reconsidéré comme une plate-forme utile pour le développement, car ce comportement est absurde.

Answer 1

Les systèmes de contrôle de source ont généralement un problème de suivi des liens durs. Vous devriez en avoir fait un lien symbolique et ajouter le lien symbolique à git et cela fonctionnerait bien. Git peut gérer les liens symboliques très bien. À moins que vous n'indiquiez d'une manière ou d'une autre à un système de contrôle de source qu'un fichier que vous ajoutez au référentiel est un lien physique, il n'a aucun moyen de le savoir et ne comparera certainement pas les inodes de tous les fichiers. Si c'est le cas.

Même les systèmes qui autorisent les liens durs essaient d'éviter de les créer à tout prix, car le nombre de problèmes créés par les liens est assez élevé et tous les bogues et incohérences sont très difficiles à suivre. Après un moment et quelques renames et coups de l'un des liens, deux équipes différentes pourraient chacune posséder une partie du lien physique dans leur partie de l'arbre source et un combat sur le contenu de l'arbre de version de l'objet s'ensuit A propos de la raison pour laquelle aucune modification n'a été apportée à votre partie de l'arborescence source, le contenu d'un fichier est en train de changer. Il est préférable d'utiliser des liens symboliques.

Answer 2

On dirait un bug git pour moi. Si je comprends bien, vous avez créé un lien à partir de Configure pour configurer et git les voit correctement comme des entités séparées, mais quand on change, ils doivent tous deux changer dans l'index git.

Ai-je raison de dire que ces liens sont en dur?

Answer 3

Je ne suis pas sûr que git surveille réellement les inodes, cela ne concerne probablement que les noms de fichiers. Jetez un oeil à cette exécution de l'échantillon, par exemple:

$ 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 

Notez que si j'enregistre un commit avec des modifications à un seul des fichiers, git enregistre une modification du fichier a et suppose b n'a pas été modifié (comme je m'attendais). En ce qui concerne git, l'autre fichier n'a pas été modifié. Si vous effectuez une réinitialisation git plus tard, les inodes du fichier ne seront plus identiques car ils diffèrent.

Je n'ai pas été en mesure de reproduire le comportement que vous avez signalé (modifications de rapports d'état Git juste après une réinitialisation matérielle) et je me demande si cela est même possible (si ce n'est pour un bug). Pouvez-vous trouver un petit exemple qui montre le comportement que vous avez observé?