windows - simbólico - union de directorios o symlink onedrive

¿Qué sucede cuando clono un repositorio con enlaces simbólicos en Windows? (3)

Ha habido muchas preguntas sobre cómo agregar soporte para enlaces simbólicos en Windows. Pero, ¿qué sucede realmente cuando clono un repositorio con enlaces simbólicos en Windows?

He estado trabajando en el soporte de Symlink en msysgit aquí:

https://github.com/frogonwheels/git (rama mrg / symlink-v * .. actualmente v2)

Las pruebas aún no se han completado, y tengo un tiempo limitado para trabajar en ellas, y no tengo una meta real a corto plazo que me motive. Sería bueno poder usar proyectos como git-annex en msysgit.

Mi trabajo se ve obstaculizado por la falta de soporte de enlaces simbólicos en el shell msys también.

Hay una línea de comandos para otorgar los privilegios sugeridos por el comando cygwin ln. (Necesitará ejecutar esto como administrador).

editrights -a SeCreateSymbolicLinkPrivilege -a $ YOUR_USER

Todo el problema de Directory vs file symlinks es un problema.

En este momento, opino que, en la medida de lo posible, nos limitamos a hacer que los enlaces simbólicos de archivos funcionen ... y no permitamos enlaces simbólicos de directorio en msysgit. No es lo ideal, pero la realidad es que cualquier solución es un poco difícil, tratar de imponer un vínculo de posibilidad sobre las realidades de las incompatibilidades de NTFS con el vínculo de posibilidad es simplemente doloroso.

Podemos probar y detectar si el objetivo es un archivo o un directorio, pero se me ocurren algunos problemas que no están en lo más alto de mi cabeza, especialmente el problema general de en qué orden se crean las entidades.

Una solución tendría un filtro para detectar los enlaces simbólicos almacenados por Git y reemplazarlos por el enlace simbólico de Windows.
Eso se detalla en " Git enlaces simbólicos en Windows "

Sin embargo, el verdadero soporte de enlaces simbólicos no es solo por ahora:
Vea el número 224 y la muy reciente discusión (en julio de 2012) sobre GitHub (que analizó):

Aquí hay tres tipos de enlaces de sistema de archivos en Windows: enlaces físicos, uniones y enlaces simbólicos.
Hardlinks y uniones están disponibles desde NT. Los enlaces físicos solo pueden apuntar a archivos, uniones solo a directorios (en el mismo volumen).
Los enlaces simbólicos disponibles desde Vista pueden apuntar a archivos o directorios, también en volúmenes diferentes.
mklink , que se envía desde Vista, puede crear todo lo anterior. Pero la forma en que se llama en el script hace que solo cree enlaces simbólicos (lo cual es bueno, IMHO, ya que se parecen más a los enlaces simbólicos de Linux).
Para pre-Vista, necesitaríamos un respaldo que cree fsutil hardlink para los archivos que usan " fsutil hardlink " (pero probablemente solo si se llama "ln" sin " -s ") y fsutils reparsepoint uniones para los directorios que usan " fsutils reparsepoint ", o simplemente llama al ln.exe original.
Además de romper las configuraciones de Windows XP, un cambio como este también romperá las configuraciones estándar de Windows 7, porque mklink requiere privilegios de administrador de forma predeterminada . Esto puede solucionarse verificando si funcionó o no, y volviendo a copiar en tales casos.
Solo para que quede constancia: recientemente jugué un poco tratando de hacer compatible el enlace simbólico en Git para Windows, pero terminé concluyendo que el "soporte del enlace simbólico" en Windows 7 y versiones posteriores es bastante inútil para emular los enlaces simbólicos de Unix.

Hay un proyecto que dice " Código abierto, 100% compatible para Windows (y la biblioteca de punto de unión) ", pero:

Desafortunadamente, los usuarios normales no tienen los permisos necesarios para crear enlaces simbólicos de forma predeterminada en Windows. Combine esto con el hecho de que no puede cambiar lo que apunta un enlace simbólico de la misma manera que requiere POSIX, los hace más o menos inútiles para nosotros. Esto ya lo escribí arriba.
Ahora, los autores pueden reclamar todo lo que quieran, esto es "100% compatible" para todo lo que me importa, pero un vistazo rápido al código fuente revela que no lo es. No proporcionan ningún respaldo, ni siquiera cargan dinámicamente la función CreateSymbolicLink . Por lo tanto, el resultado en las versiones de Windows no compatibles con enlaces simbólicos será un fallo con un error de símbolo faltante.

Desde la versión 1.5.3 del cliente nativo de Git, git clone y git init sondearán el sistema de archivos de destino para el soporte de core.symlinks simbólicos y establecerán la configuración del repositorio local para los core.symlinks de core.symlinks de core.symlinks consecuencia, es decir, en false para FAT o NTFS. Esto hace que los enlaces simbólicos creados y confirmados, por ejemplo, bajo Linux, aparezcan como archivos de texto sin formato que contienen el texto del enlace en Windows (consulte la documentación de git config en core.symlinks para obtener más información).

Desde Git para Windows versión 2.10.2, el instalador tiene una opción explícita para habilitar el soporte de enlace simbólico .

En versiones anteriores de Git para Windows, puedes establecer manualmente core.symlinks en true que permite a Git crear enlaces simbólicos bajo las siguientes restricciones:

Los enlaces simbólicos solo están disponibles en Windows Vista y versiones posteriores.
Los enlaces simbólicos solo funcionarán en NTFS, no en FAT.
SeCreateSymbolicLinkPrivilege ser administrador y / o tener el privilegio SeCreateSymbolicLinkPrivilege .
Los enlaces simbólicos en sistemas de archivos remotos están deshabilitados por defecto.
Los enlaces simbólicos de Windows están escritos.
Muchos programas no comprenden los enlaces simbólicos (que incluyen la versión anterior del Explorador de Windows).

Más details están disponibles en el wiki de Git para Windows.

En versiones anteriores de Git para Windows configurando manualmente los core.symlinks manualmente en true después de clonar y restablecer su árbol de trabajo, obtendría mensajes de error similares a

$ git reset --hard HEAD error: unable to create symlink directory (Function not implemented) error: unable to create symlink linux-links/this_is_a_symbolic_link_to_file (Function not implemented) fatal: Could not reset index file to revision ''HEAD''.

Como nota al margen, el cliente JGit no probó el sistema de archivos de destino para la compatibilidad con el enlace simbólico hasta su versión 3.3, por lo que la configuración de core.symlinks se redujo a lo que fuera la configuración del sistema / Git global. Comenzando con las sondas JGit de la versión 3.3 para compatibilidad con enlaces simbólicos, pero parece ser demasiado conservador, estableciendo core.symlinks = false en algunos casos en los que los enlaces simbólicos en realidad serían compatibles .

Puedes ingresar a https://github.com/sschuberth/git-playground que contiene un montón de enlaces creados en Linux para probar.