Git et hard links

Question

Considérant que Git ne reconnaît pas les liens symboliques qui pointent en dehors du dépôt, y a-t-il un problème à utiliser des liens durs ?

Git pourrait-il les briser ? Pouvez-vous m'indiquer des informations détaillées ?

Answer 1

L'objet 'tree', qui représente les répertoires dans Git, stocke les noms de fichiers et (sous-ensemble de) permissions. Il ne stocke pas le numéro d'inode (ou tout autre type d'identifiant de fichier). Par conséquent, liens solides ne peut pas être représenté dans git du moins pas sans des outils tiers tels que métastore o git-cache-meta (et je ne suis pas sûr que ce soit possible même avec ces outils).

Git essaie de ne pas toucher aux fichiers qu'il n'a pas besoin de mettre à jour, mais vous devez prendre en compte le fait que git n'essaie pas de préserver les hardlinks, donc ils peuvent être cassés par git.

---

À propos de 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 tels liens me semble douteuse, car le fait que ces liens symboliques soient rompus ou non dépend de la disposition du système de fichiers. à l'extérieur de dépôt git, et non sous le contrôle de git.

Answer 2

J'ai découvert que, en utilisant des crochets, vous pouvez capturer le git pull événement (quand il y a quelque chose à tirer...) en écrivant le gestionnaire d'événement script pour .git/hooks/post-merge archivo.

D'abord, vous devez chmod +x il.

Ensuite, mettez le ln à l'intérieur pour recréer des liens durs à chaque tirage. Neat huh !

Ça marche, j'en avais juste besoin pour mon projet et ls -i montre que les fichiers ont été 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 constater, le chemin d'accès à tout fichier de votre référentiel doit commencer par $GIT_DIR puis ajoutez le chemin relatif partiel au fichier.

Egalement important : -f est nécessaire, car vous recréez le fichier de destination.

EDITAR

Les clients git modernes semblent prendre en charge les liens symboliques et les liens durs à l'intérieur du dépôt de manière naturelle, même lorsqu'ils sont poussés vers un emplacement distant puis clonés à partir de celui-ci. Je n'ai plus jamais eu besoin de faire des liens en dehors d'un dépôt git cependant...

$ mkdir tmp
$ cd tmp
$ git --version
git version 2.24.3 (Apple Git-128)
$ git init .
Initialized empty Git repository in /Users/teixeira/tmp/.git/
$ mkdir x
$ cd x
$ echo 123 > original
$ cat original
123
$ cd ..
$ ln -s x/original symlink
$ cat symlink
123
$ ln x/original hardlink
$ cat hardlink
123
$ git add .
$ git commit -m 'Symlink and hardlink commit'
[master (root-commit) 8df3134] Symlink and hardlink commit
 3 files changed, 3 insertions(+)
 create mode 100644 hardlink
 create mode 120000 symlink
 create mode 100644 x/original

Clonage à partir du dépôt git local

$ cd
$ git clone tmp/ teste_tmp
Cloning into 'teste_tmp'...
done.
$ cd teste_tmp/
$ ls
hardlink  symlink  x
$ cat symlink
123
$ cat hardlink
123

Clonage à partir d'un référentiel distant

$ cd ~/tmp
$ git remote add origin https://github.com/myUser/myRepo.git
$ git push origin master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 361 bytes | 361.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To https://github.com/myUser/myRepo.git
 + 964dfce...8df3134 master -> master
$ cd ../
$ git clone https://github.com/myUser/myRepo.git
Cloning into 'myRepo'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.
$ cd myRepo/
$ cat symlink
123
$ cat hardlink
123

https://github.com/mokacoding/symlinks souligne également une chose importante : les liens symboliques doivent être définis de manière relative.

Answer 3

De ce problème de msysgit

Les points de jonction ne sont pas des liens symboliques ; par conséquent, les liens symboliques ne sont tout simplement pas supportés dans msysGit. simplement non supportés dans msysGit.

Aussi, les liens durs n'ont jamais été suivis par Git .

La question était orientée vers Windows (puisqu'il s'agit de msysgit) et le débat sur le support potentiel de symlink.
Mais le commentaire sur la liaison dure concerne Git en général.

Answer 4

Google "git preserve hard links" et il montre que git ne sait pas comment préserver la structure des liens durs (AFAIK), peut-être à dessein.

Mes projets Web utilisent les 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 veux apporter des modifications à index.php, je le modifie à un endroit et les liens directs (pages de détail des produits) pointent vers les modifications - sauf que git ne préserve pas cette relation lors du clonage et du transfert sur d'autres ordinateurs.

me@server:www$ git pull

sur une autre machine créera un nouvel index.php pour chaque lien dur.