J'ai découvert qu'en utilisant des crochets, vous pouvez capturer le git pull événement (quand il y a quelque chose à extraire ...) écrire le gestionnaire d'événements de script sur .git/hooks/post-merge fichier.
Vous devez d'abord chmod +x il.
Ensuite, mettez le ln commandes à l'intérieur pour recréer des liens physiques à chaque tirage. Super hein !
Cela fonctionne, 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.
Aussi important :-f est nécessaire, car vous recréez le fichier de destination.
MODIFIER
Le client git moderne semble prendre en charge naturellement les liens symboliques et les liens physiques à l'intérieur du référentiel, même lorsqu'il est poussé vers un emplacement distant, puis cloné à partir de celui-ci. Je n'ai plus jamais eu besoin de créer un lien en dehors d'un dépôt git...
$ 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.
L'objet 'tree', représentant les répertoires dans Git, stocke le nom du fichier et (un sous-ensemble de) permissions. Il ne stocke pas le numéro d'inode (ou tout autre type d'identifiant de fichier). Par conséquent, des liens physiques ne peut pas être représenté dans git , du moins pas sans outils tiers tels que metastore ou 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 tenir compte du fait que git n'essaie pas de conserver les liens physiques, afin qu'ils puissent être rompus par git.
À propos des liens symboliques pointant vers l'extérieur 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 est douteuse pour moi, car si ces liens symboliques seraient rompus ou non dépend de la disposition du système de fichiers à l'extérieur référentiel git, et non sous le contrôle de git.
À 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 durs n'ont jamais été suivis par Git .
Le problème était orienté Windows (puisqu'il s'agissait de msysgit) et débattait sur le support potentiel du lien symbolique.
Mais le commentaire sur le lien dur concerne Git en général.