git hard links - sait-il qu'un fichier est un lien dur?


16

J'ai commencé à utiliser des liens physiques au lieu de liens symboliques pour organiser les fichiers ...

Je fais cela pour les photos que je prends pour les classer ainsi que pour indiquer celles que je veux imprimer, etc.

J'utilise git pour sauvegarder mes images et il semble que git pensait qu'il s'agissait de nouveaux fichiers car le référentiel a augmenté d'environ 1 Go. Git réussit très bien à détecter les renommages si je n'utilise pas git pour renommer le fichier, mais gère-t-il également les liens durs?

Walter


2
Tous les fichiers normaux sont des liens durs. Peut-être que vous vouliez dire "fichiers avec plusieurs liens durs"?
Ignacio Vazquez-Abrams

Oui, c'est ce que je voulais dire.
Walter

1
Corrigez-moi si je me trompe, mais ne donne-t-il pas plus de piste content? Pourquoi serait-il important que les fichiers aient le même contenu, alors - après tout, ils sont techniquement le même fichier.
new123456

1
Pour les personnes qui tombent sur cela - envisagez peut-être d'utiliser des liens symboliques à la place? stackoverflow.com/q/954560/492
CAD bloke

Il semble que vous souhaitiez un système de fichiers basé sur des balises.
Nayuki

Réponses:


14

La multiplication des fichiers suivis liés ne fera pas grandir le magasin d'objets de Git puisque chaque lien sera représenté par le même objet blob exact. Cependant, votre arbre de travail pourrait finir par croître en raison de liens rompus.

Git ne vérifie pas si les fichiers d'arbre de travail suivis sont des liens physiques vers le même fichier.

Git laissera les fichiers d'arborescence de travail liés, multipliés et suivis seuls si vous ne lui demandez pas de faire quoi que ce soit qui impliquerait de modifier le contenu de ces chemins d'accès ou de supprimer les entrées du répertoire des chemins d'accès. Mais, si vous deviez (par exemple) extraire une ancienne validation ou branche puis revenir à votre branche / validation normale la plus récente, alors Git finira par «casser» les liens durs (en remplaçant les noms de chemins affectés par de nouveaux (mais identiques) ) au lieu de recréer votre situation de liens multiples).

Pour récupérer votre statut de lien multiplié, vous pouvez écrire un programme pour rechercher des fichiers identiques et les relier à l'un des fichiers. Une telle opération de «réassociation» peut être plus compliquée si tous les liens ne se trouvent pas dans l'arborescence de travail elle-même ou, du moins, pas dans un emplacement «externe» facilement identifiable (c'est-à-dire qu'il sera probablement difficile de récupérer les liens si vous liez Des fichiers "aléatoires" de partout dans votre répertoire personnel dans un référentiel de "sauvegarde" et en utilisant Git pour modifier l'arborescence de travail).

L'idée est apparue sur la liste de diffusion Git:


Pour les linux basés sur Debian, il existe l'outil hardlink ( packages.debian.org/search?keywords=hardlink ) qui est capable de faire cette opération de liaison. malheureusement, ce n'est pas très rapide
Daniel Alder

Je cours hardlinktous les soirs /var/lib/jenkins.
Amédée Van Gasse du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.