Teniendo en cuenta que Git no reconoce los enlaces simbólicos que apuntan fuera del repositorio, ¿hay algún problema al usar enlaces duros?Git y enlaces duros
¿Podría Git romperlos? ¿Puede indicarme información detallada?
El objeto 'árbol', que representa directorios en Git, almacena el nombre de archivo y (subconjunto de) permisos. No almacena el número de inodo (u otro tipo de identificación de archivo). Por lo tanto, enlaces durosno se pueden representar en git, al menos no sin herramientas de terceros como metastore o git-cache-meta (y no estoy seguro si es posible incluso con esas herramientas).
Git intenta no tocar los archivos que no necesita actualizar, pero debe tener en cuenta que git no intenta preservar los enlaces duros, por lo que pueden descomponerse mediante git.
Sobre enlaces simbólicos apuntando fuera repositorio: Git tiene ningún problema con ellos y debe preservar contenidos de los enlaces simbólicos ... pero la utilidad de estos enlaces es dudosa para mí, como si esos enlaces simbólicos se romperían o no depende del diseño del sistema de archivos fuera de git repository, y no bajo el control de git.
Los enlaces simbólicos a rutas fuera del repositorio pueden ser útiles. Los he usado en webapps para apuntar a bases de datos o archivos de medios no rastreados por el repositorio. De esta forma, el archivo de configuración de la aplicación web puede apuntar a una ruta estática, pero la ubicación real de esa ruta puede variar entre el desarrollo local y el entorno del servidor. – mipadi
@mipadi: Por cierto. El gitweb moderno tiene un caso especial para mostrar enlaces simbólicos que conducen después de la normalización fuera del repositorio. –
Sí, los enlaces simbólicos fuera del repositorio están bien. Los usé para apuntar a un directorio de datos masivo que no necesitaba (o quería) versionado. Generalmente uso enlaces relativos. Entonces, en el caso de que el repo y el directorio de datos tuvieran que sentarse uno al lado del otro en algún directorio padre. Puedes hacer trucos increíbles con enlaces simbólicos a ../foo. –
De esta msysgit issue
Los puntos de unión son enlaces no simbólicos; por lo tanto, los enlaces simbólicos son simplemente no compatibles en msysGit.
También, enlaces duros nunca fueron rastreados por Git.
El problema estaba orientado a Windows (ya que se trata de msysgit) y debate sobre el posible soporte de symlink.
Pero el comentario sobre el enlace físico concierne a Git en general.
Google 'git preserva enlaces duros' y muestra que git no sabe cómo preservar la estructura del enlace duro AFAIK, quizás por diseño.
proyectos Web de la mina utilizan enlaces duros 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)
[email protected]:www/products$ ls -l index.php
-rwxr-xr-x 3 me me 1958 Aug 22 22:10 index.php*
Si quería hacer cambios a 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 tirando de otras computadoras.
[email protected]:www$ git pull
en otra máquina creará un nuevo index.php para cada enlace duro.
Debería implementar algún tipo de enrutamiento en su aplicación web. Los enlaces duros son extraños. – Nowaker
Sí, al menos use enlaces simbólicos. :) –
Ok, ahora se trata de una respuesta tardía = D
descubrí que, usando ganchos, puede capturar el evento git pull (cuando hay algo para tirar ...) escribir el controlador de eventos script para .git/hooks/post-merge archivo.
Primero, usted tiene que chmod +x él.
A continuación, coloque los comandos ln en su interior para recrear los enlaces duros en cada extracción. Neat eh!
Funciona, solo lo necesitaba para mi proyecto y ls -i muestra que los archivos se vincularon automáticamente después de 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 se puede ver, el camino a cualquier archivo en su repositorio debe comenzar con $GIT_DIR, a continuación, añadir la ruta relativa al archivo parcial.
También es importante: -f es necesario porque está recreando el archivo de destino.
Parece que cada vez que agrega un enlace fijo a su repositorio, también necesita agregar manualmente una línea a su secuencia de comandos de enlace posterior a la fusión. Sería bueno si su gancho precompromiso lo hiciera completamente automático, detectando enlaces duros (y simbólicos) en su confirmación y escribiendo las líneas apropiadas para su archivo posterior a la fusión. ¡Git no tendría que almacenar información de inode en el repositorio, sino que almacenaría bits de él en los ganchos! Pero qué lío si el archivo vinculado fuera rastreado en otro repositorio git ... ¿una edición del archivo en un lugar se propagaría al otro repo sin problemas? ¿Se funde perpetuamente con un bucle circular de empujar/jalar? – hobs
Enfoque inteligente, pero es desafortunado que Git no rastree enlaces duros, incluso los represente potencialmente como copias en sistemas de archivos que no admiten enlaces duros. –
¿Qué estás tratando de hacer y por qué? Un enlace fijo no es diferente de un archivo normal. Si alguna vez extraes una nueva versión de otro repositorio, sobrescribiría la que tienes; ¿de qué sirve vincular algo fuera del repositorio? –
Git reconocerá los enlaces simbólicos que apuntan a una ruta fuera del repositorio. – mipadi
No mipadi, la única forma es agitando los archivos en el repositorio y los enlaces simbólicos en su ubicación "real" –