Teniendo en cuenta que Git no reconoce los enlaces simbólicos que apuntan fuera del repositorio, ¿hay algún problema al utilizar enlaces físicos?
¿Podría Git romperlos? ¿Puede indicarme información detallada?
Teniendo en cuenta que Git no reconoce los enlaces simbólicos que apuntan fuera del repositorio, ¿hay algún problema al utilizar enlaces físicos?
¿Podría Git romperlos? ¿Puede indicarme información detallada?
Respuestas:
El objeto 'árbol', que representa directorios en Git, almacena el nombre del archivo y (subconjunto de) permisos. No almacena el número de inodo (u otro tipo de identificación de archivo). Por lo tanto, los enlaces duros no se pueden representar en git , al menos no sin herramientas de terceros como metastore o git-cache-meta (y no estoy seguro de si es posible incluso con esas herramientas).
Git intenta no tocar archivos que no necesita actualizar, pero debes tener en cuenta que git no intenta preservar los enlaces duros, por lo que pueden romperse con git.
Acerca de los enlaces simbólicos que apuntan fuera del repositorio : git no tiene problemas con ellos y debería preservar el contenido de los enlaces simbólicos ... pero la utilidad de tales enlaces es dudosa para mí, ya que si esos enlaces simbólicos se romperían o no depende del diseño del sistema de archivos fuera del repositorio de git y no bajo el control de git.
Descubrí que, usando ganchos, puedes capturar el git pull
evento (cuando hay algo que tirar ...) escribiendo el controlador de eventos del script en el .git/hooks/post-merge
archivo.
Primero, tienes que chmod +x
hacerlo.
Luego, coloque los ln
comandos dentro de él para recrear enlaces duros en cada extracción. ¡Genial eh!
Funciona, solo lo necesitaba para mi proyecto y ls -i
muestra que los archivos se vincularon automáticamente después pull
.
Mi ejemplo 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
IMPORTANTE: Como puede ver, la ruta a cualquier archivo en su repositorio debe comenzar con $GIT_DIR
, luego agregar la ruta relativa parcial al archivo.
También importante: -f
es necesario, porque está recreando el archivo de destino.
El cliente moderno de git parece admitir enlaces simbólicos y enlaces físicos dentro del repositorio de forma natural, incluso cuando se empuja a una ubicación remota y luego se clona desde ella. Sin embargo, nunca volví a tener la necesidad de vincularme fuera de un repositorio de 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
$ cd
$ git clone tmp/ teste_tmp
Cloning into 'teste_tmp'...
done.
$ cd teste_tmp/
$ ls
hardlink symlink x
$ cat symlink
123
$ cat hardlink
123
$ 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 también señala una cosa importante: los enlaces simbólicos deben definirse relativamente.
De este problema de msysgit
Los puntos de unión no son enlaces simbólicos; por lo tanto, los enlaces simbólicos simplemente no son compatibles con msysGit.
Además, Git nunca rastreó los enlaces duros .
El problema estaba orientado a Windows (ya que se trata de msysgit) y se debatió sobre el posible soporte del enlace simbólico.
Pero el comentario sobre el enlace duro se refiere a Git en general.
Google 'git preserve hard links' y muestra que git no sabe cómo preservar la estructura de hard link AFAIK, quizás por diseño.
Los proyectos web míos utilizan enlaces físicos de la siguiente manera:
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 quisiera hacer cambios en index.php, lo cambio en un lugar y los enlaces duros (páginas de detalles del producto) apuntan a los cambios, excepto que git no conserva esta relación durante la clonación y extracción en otras computadoras.
me@server:www$ git pull
en otra máquina creará un nuevo index.php para cada enlace físico.
hardlink --ignore-time
sobre /var/lib/jenkins
, para recuperar algo de espacio en disco. Durante el día, algunos archivos se desvinculan de nuevo después git pull
o, mvn compile
pero eso está bien, espero que eso suceda. Si git preservara los enlaces duros, entonces mi estrategia de reciclaje de espacio en disco no funcionaría.