Git et liens durs

91

Étant donné que Git ne reconnaît pas les liens symboliques qui pointent en dehors du référentiel, y a-t-il un problème avec les liens physiques?

Git pourrait-il les casser? Pouvez-vous s'il vous plaît me diriger vers des informations détaillées?

— Alfredo Palhares
source

2

Qu'essayez-vous de faire et pourquoi? Un lien physique n'est pas différent d'un fichier normal. Si jamais vous deviez extraire une nouvelle version d'un autre référentiel, elle écraserait celle que vous aviez - quel est l'intérêt de créer un lien vers quelque chose en dehors du référentiel?

— Carl Norum

1

Git reconnaîtra les liens symboliques qui pointent vers un chemin en dehors du référentiel.

— mipadi le

Pas de mipadi, le seul moyen est d'agiter les fichiers dans le repo et les liens symboliques dans leur emplacement "réel"

— Alfredo Palhares

84

L'objet 'tree', représentant les répertoires dans Git, stocke le nom de fichier et le (sous-ensemble de) permissions. Il ne stocke pas le numéro d'inode (ou tout autre type d'identifiant de fichier). Par conséquent, les liens durs ne peuvent pas être représentés dans git , du moins pas sans outils tiers tels que metastore ou git-cache-meta (et je ne suis pas sûr que cela soit possible même avec ces outils).

Git essaie de ne pas toucher les fichiers qu'il n'a pas besoin de mettre à jour, mais vous devez tenir compte du fait que git n'essaye pas de préserver les liens physiques, afin qu'ils puissent être interrompus par git.

À propos des liens symboliques pointant en dehors du référentiel : git n'a aucun problème avec eux et devrait préserver le contenu des liens symboliques ... mais l'utilité de ces liens est douteuse pour moi, car le fait que ces liens symboliques soient rompus ou non dépend de la disposition du système de fichiers en dehors du référentiel git , et non sous le contrôle de git.

— Jakub Narębski
source

4

Les liens symboliques vers des chemins en dehors du dépôt peuvent être utiles. Je les ai utilisés dans des applications Web pour pointer vers une base de données ou des fichiers multimédias non suivis par le repo. De cette façon, le fichier de configuration de l'application Web peut pointer vers un chemin statique, mais l'emplacement réel de ce chemin peut varier entre les environnements de développement local et de serveur.

— mipadi le

@mipadi: BTW. Gitweb moderne a un cas particulier pour afficher les liens symboliques après la normalisation en dehors du référentiel.

— Jakub Narębski

6

Oui, les liens symboliques en dehors du dépôt sont très bien. Je les ai utilisés pour pointer vers un répertoire de données massif dont je n'avais pas besoin (ou que je ne voulais pas) versionné. En général, j'utilise des liens relatifs. Ainsi, dans certains cas, le dépôt et le répertoire de données devaient être placés l'un à côté de l'autre dans un répertoire parent. Vous pouvez faire des trucs incroyables avec un lien symbolique vers ../foo.

— Adrian Ratnapala

Malheureusement, le dépôt Git pour metastore (git: //git.hardeman.nu/metastore.git) n'est plus disponible.

— Derek Mahar

1

github.com/danny0838/git-store-meta est une alternative à git-cache-meta .

— Derek Mahar

21

J'ai découvert qu'en utilisant des hooks, vous pouvez capturer l' git pullévénement (quand il y a quelque chose à extraire ...) en écrivant le gestionnaire d'événements de script dans un .git/hooks/post-mergefichier.

Tout d'abord, vous devez le faire chmod +x.

Ensuite, mettez les lncommandes à l'intérieur pour recréer des liens physiques à chaque pull. Neat hein!

Cela fonctionne, j'en avais juste besoin pour mon projet et ls -imontre que les fichiers étaient automatiquement liés après pull.

Mon exemple de .git/hooks/post-merge:

#!/bin/sh
ln -f $GIT_DIR/../apresentacao/apresentacao.pdf $GIT_DIR/../capa/apresentacao.pdf
ln -f $GIT_DIR/../avaliacoesMono/avaliacao_monografias_2011_Nilo.pdf $GIT_DIR/../capa/avaliacoes.pdf
ln -f $GIT_DIR/../posters/poster_Nilo_sci.pdf $GIT_DIR/../capa/poster.pdf
ln -f $GIT_DIR/../monografia/monografia_Nilo.pdf $GIT_DIR/../capa/monografia_Nilo.pdf

IMPORTANT: comme vous pouvez le voir, le chemin d'accès à n'importe quel fichier de votre référentiel doit commencer par $GIT_DIR, puis ajouter le chemin relatif partiel au fichier.

Également important: -fest nécessaire, car vous recréez le fichier de destination.

— Niloct
source

11

Il semble donc que chaque fois que vous ajoutez un lien physique à votre dépôt, vous devez également ajouter manuellement une ligne à votre script hook post-fusion. Ce serait bien si votre hook pré-commit rendait cela entièrement automatique - détectant les liens physiques (et symboliques) dans votre commit et écrivant les lignes appropriées dans votre fichier post-fusion. Git n'aurait pas à stocker les informations sur les inodes dans le référentiel, il en stockerait des bits dans les hooks! Mais quel désordre si le fichier lié était suivi dans un autre dépôt git ... une modification du fichier à un endroit se propagerait-elle facilement à l'autre dépôt? Perpetual fusionne avec une boucle de poussée / traction circulaire?

— plaques de cuisson

Approche intelligente, mais il est regrettable que Git ne suive pas les liens physiques, voire les représente potentiellement comme des copies sur des systèmes de fichiers qui ne prennent pas en charge les liens physiques.

— Derek Mahar

8

À partir de ce problème msysgit

Les points de jonction ne sont pas des liens symboliques; par conséquent, les liens symboliques ne sont tout simplement pas pris en charge dans msysGit.

De plus, les liens physiques n'ont jamais été suivis par Git .

Le problème était orienté Windows (puisqu'il s'agit de msysgit) et le débat sur le support potentiel de symlink.
Mais le commentaire sur le lien dur concerne Git en général.

— VonC
source

2

Google 'git préserve les liens durs' et cela montre que git ne sait pas comment préserver la structure des liens durs AFAIK, peut-être par conception.

Mes projets Web utilisent des liens physiques comme suit:

www/products/index.php
www/products/dell_latitude_id577/index.php #(hard linked to above)
www/products/dell_inspiron_id323/index.php #(hard linked again to above)

me@server:www/products$ ls -l index.php
-rwxr-xr-x 3 me me 1958 Aug 22 22:10 index.php*

Si je voulais apporter des modifications à index.php, je le change en un seul endroit et les liens physiques (pages de détails du produit) pointent vers les changements - sauf que git ne conserve pas cette relation pendant le clonage et l'extraction sur d'autres ordinateurs.

me@server:www$ git pull

sur une autre machine créera un nouveau index.php pour chaque lien physique.

— xce_git
source

7

Vous devez implémenter une sorte de routage dans votre application Web. Les liens durs sont bizarres.

— Nowaker

5

Ouais, utilisez au moins des liens symboliques. :)

— Andres Riofrio

2

C'est en fait ce que je veux, je ne veux pas que git préserve les liens durs. J'ai un répertoire Jenkins avec des tonnes de répertoires d'espace de travail, et à cause des pipelines multibranches, il y a beaucoup de duplication. J'ai donc un travail de nuit qui fonctionne hardlink --ignore-timesur /var/lib/jenkins, pour récupérer l' espace disque. Au cours de la journée, certains fichiers sont à nouveau dissociés après git pullou, mvn compilemais c'est correct, je m'attends à ce que cela se produise. Si git devait conserver les liens durs, ma stratégie de recyclage de l'espace disque ne fonctionnerait pas.

— Amedee Van Gasse