¿Existen dificultades para poner $ HOME en git en lugar de simular los archivos de puntos?

Durante muchos años, he $HOMErevisado todo mi directorio en Subversion. Esto ha incluido todos mis archivos de puntos y perfiles de aplicación, muchos scripts, herramientas y hacks, mi estructura de directorio de inicio básica preferida, no pocos proyectos extraños y un almacén de datos aleatorios. Fue algo bueno. Mientras duro.

Pero se ha ido de las manos. La comprobación básica es la misma en docenas de sistemas, pero no todas esas cosas son apropiadas para todas mis máquinas. Ni siquiera funciona bien con diferentes distribuciones.

Estoy en el proceso de limpiar la casa: separar los datos donde pertenecen, dividir algunos scripts como proyectos separados, arreglar algunos enlaces rotos en cosas que deberían automatizarse, etc.

Mi intención es reemplazar subversioncon gitla comprobación de nivel superior de $HOME, pero me gustaría reducir esto a las cosas que me gustaría tener en TODOS mis sistemas, es decir, archivos de puntos, algunos directorios y algunos scripts personalizados básicos.

Al leer en línea, muchas personas parecen estar haciendo esto usando el enfoque de enlace simbólico: clonar en un subdirectorio y luego crear enlaces simbólicos desde $HOMEel repositorio. Después de haber tenido mi $HOMEcontrol de versión completo durante más de una década, no me gusta la idea de este enfoque y no puedo entender por qué las personas parecen tan reacias al método de pago directo. ¿Hay escollos que necesito saber específicamente para gitun pago de nivel superior $HOME?

_{PD: en parte como un ejercicio de buena codificación, también estoy planeando hacer público mi pago raíz en github. ¡Da miedo la cantidad de información confidencial de seguridad que he permitido recopilar en archivos que pueden compartirse sin pensarlo dos veces! Contraseña WiFi, claves RSA sin contraseña, etc. ¡Eeek!}

Sí , hay al menos un obstáculo importante cuando se considera gitadministrar un directorio de inicio que no le preocupa subversion.

Git es codicioso y recursivo por defecto .

Subversion ignorará ingenuamente todo lo que no sabe y deja de procesar carpetas hacia arriba o hacia abajo desde su pago cuando llega a una que no conoce (o que pertenece a un repositorio diferente). Git, por otro lado, sigue recurriendo a todos los directorios secundarios, lo que hace que los pagos anidados sean muy complicados debido a problemas de espacio de nombres. Dado que su directorio de inicio también es probablemente el lugar donde realiza el pago y trabaja en otros repositorios de git, tener su directorio de inicio en git seguramente hará que su vida sea un desastre imposible.

Como resultado, esta es la razón principal por la que las personas revisan sus archivos de puntos en una carpeta aislada y luego hacen un enlace simbólico en ella. Mantiene a Git fuera del camino al hacer cualquier otra cosa en cualquier directorio secundario de su $HOME. Si bien esto es puramente una cuestión de preferencia si convierte su casa en subversión, se convierte en una cuestión de necesidad si usa git.

Sin embargo , hay una solución alternativa. Git permite algo llamado "raíz falsa" donde toda la maquinaria del repositorio está oculta en una carpeta alternativa que se puede separar físicamente del directorio de trabajo de pago. El resultado es que el kit de herramientas git no se confundirá: ni siquiera VERÁ su repositorio, solo la copia de trabajo. Al configurar un par de variables de entorno, puede indicarle a git dónde encontrar los productos para esos momentos en los que administra su directorio de inicio. Sin las variables de entorno establecidas, nadie es más sabio y su hogar parece un archivo clásico.

Para que este truco fluya un poco más suave, existen algunas herramientas excelentes. La lista de correo de vcs-home parece ser el lugar de facto para comenzar, y la página acerca tiene un resumen conveniente de los howtos y las experiencias de las personas. En el camino hay algunas pequeñas herramientas ingeniosas como vcsh , mr . Si desea mantener su directorio de inicio directamente en git, vcsh es casi una herramienta imprescindible. Si termina dividiendo su directorio de inicio en varios repositorios detrás de escena, combínelo vcshcon mruna forma rápida y no muy sucia de administrarlo todo de una vez.

No quisiera que todo mi directorio de inicio se registre en el control de versiones simplemente porque significa que cada subdirectorio al que acceda tendría el contexto de control de versiones de mi directorio de inicio. Comandos como git checkouttendrían una acción real en ese caso, causando problemas si accidentalmente ejecuto algo desde el directorio incorrecto, ya sea que sea algo en gitsí mismo o un script que llame a git.

También hace que sea más probable que agregue algo al repositorio que no desea, lo que no hubiera sido un problema cuando tenía todo registrado, pero ahora se convierte en un problema. ¿Qué sucede si accidentalmente agrega un archivo de clave privada (tal vez por costumbre) y lo empuja a github?

Dicho esto, creo que las principales desventajas no son realmente técnicas, solo querer salvarme de mí mismo.

En cuanto a los enlaces simbólicos: podría clonar su repositorio en un subdirectorio y tener un script que actualice los enlaces simbólicos que deban actualizarse. Sin embargo, la cantidad de mantenimiento requerida para este script podría ser mayor que los beneficios de tenerlo; la simulación podría ser menos trabajo.

Con los enlaces simbólicos, también puede hacer fácilmente adiciones específicas de la distribución (o incluso específicas del host) que se registran en git. Su script de actualización de enlace simbólico ignorará los archivos destinados a plataformas incompatibles o diferentes hosts, y solo actualizará los apropiados.

Algo como:

HOMEREPO=$HOME/homerepo
HOST=$(hostname)
UNAME=$(uname)

for dotfile in $HOMEREPO/shared/* $HOMEREPO/host-$HOST/* $HOMEREPO/uname-$UNAME/*
do
    target=$HOME/$(basename $dotfile)
    [ ! -r $target ] && ln -s $dotfile $target
done

Personalmente: uso enlaces simbólicos y no enlazo directorios; solo los archivos dentro. Esto me da cierta flexibilidad para realizar cambios locales en el sitio en esos directorios (es decir, agregar / eliminar archivos). Configurar mi cuenta en un nuevo sistema es tedioso porque tengo que recrear todos los enlaces simbólicos a mano.

Para dar otro punto de vista: tengo mi $ HOME bajo git desde hace algún tiempo y no encontré ningún inconveniente. Obviamente no sincronizo este repositorio de git con github; Yo uso un servicio que tiene repositorios privados. Tampoco pongo ningún archivo multimedia o descargas o paquetes bajo control de git.

• git status es una especie de lista de verificación "para hacer, para limpiar".

• Tengo un ~/tmppara cosas temporales, que es ignorado.

• Me gusta ver en git statuscualquier cosa que un software instalado recientemente se atreva a agregar a mi $ HOME, ya menudo elimine estos archivos, o incluso desinstale a los culpables.

• Agrego manualmente los archivos y directorios locales realmente útiles .gitignore, que tienen el beneficio de "saber lo que haces al instalar cosas".

• Si construyo una nueva VM o instalo una nueva PC, simplemente clono mi hogar remoto en $ HOME y tengo todo lo que necesito de inmediato.

• Cosas como vundle para los complementos vim ya no son necesarios.

No me gusta la complejidad. Cuando modifico cualquier archivo rc, simplemente lo hago, me comprometo y presiono. Luego, como reflejo, git pull en $ HOME cada dos días, y siempre tengo la última configuración. Es así de simple.

Máquinas actualmente bajo este régimen: computadora portátil doméstica, PC de trabajo, VM de trabajo, más 3 o 4 servidores remotos.

He intentado ambos y preferí el enfoque de enlace simbólico al final:

• Echa un vistazo a donde sea
• make install
• Cierre sesión y vuelva a iniciarla para cargar la configuración X

Desventajas

• Tiene que mover archivos al repositorio antes de agregarlos
• Tiene que mantener la lista de enlaces simbólicos en el Makefile

Ventajas:

• No es necesario un .gitignorearchivo masivo (tengo 133 archivos de puntos en ~mi humilde caja de Ubuntu)
• Puede mantener las secuencias de comandos de mantenimiento y otras ~cosas relacionadas (como Makefiley cleanup.sh) fuera del camino
• ¿Puede la versión controlar configuraciones personales y públicas por separado?

Restricciones

• A diferencia de @mrb, solo creo enlaces simbólicos en ~. Eso mantiene la simbología simple y hace que sea trivial notar nuevos archivos, por ejemplo ~/.vim, a costa de un .gitignoremantenimiento muy raro .

Las dos últimas ventajas inclinaron la balanza en mi caso: no quiero saturar el directorio de inicio y quiero mantener el contenido privado y público claramente separado.

La única aplicación que conozco que tiene (o al menos ha tenido) problemas con el manejo de enlaces simbólicos fue Pidgin: siguió sobrescribiendo mis enlaces simbólicos con archivos normales.

Aquí hay uno: si intenta hacerlo git rebase -i --rooty se ha registrado en .gitconfigla primera confirmación en el repositorio, git eliminará temporalmente el .gitconfigarchivo, lo que a su vez le impedirá finalizar la operación de rebase, ya que requiere su nombre y su correo electrónico para hacerlo. eso, que se almacenan en ese archivo.

Puede configurarlos de nuevo y hacerlo git rebase --continue, pero después de que hice eso y terminé la operación de rebase, mi repositorio git había obtenido una confirmación vacía sin un mensaje de confirmación antes de la confirmación que anteriormente era la primera confirmación en el depósito, que no sé cómo deshacerse de

No sé qué sucede si lo haces git rebase -i <commit>, y luego .gitconfigse registra junto con cualquier confirmación <commit>.

Quizás la solución más fácil es abstenerse de agregar .gitconfigal repositorio y, en su lugar, enumerarlo .gitignore.

Así es como lo hago:

1. Instale un Linux limpio (no es necesario, pero hace la vida más agradable en el paso 4)
2. instalar etckeeper
3. corre git initen tu casa
4. crea .gitignore y agrega todo lo que parece que no te interesa o que puede cambiar mucho. Asegúrese de agregar cosas como *.cache, *.locketc. No recomiendo agregar/*porque no se le notificará automáticamente cuando se agregue algo nuevo a su hogar. Es un enfoque de lista negra frente a un enfoque de lista blanca, donde básicamente quiero mantener mi configuración para todo el software, excepto para las cosas volátiles y algunos software que no me importan. Cuando más tarde fusiones, migres o compares sistemas, ser capaz de diferenciar todo es bastante útil. Puede configurar sus nuevos sistemas mucho más rápido que si solo tuviera .bashrc y algunos otros archivos de puntos almacenados. De esta manera, mantendrá la configuración que de otro modo podría establecer a través de la GUI, y no sabrá qué archivos de puntos almacenan la configuración. (Si alguna vez resulta que ha comprometido archivos volátiles, aún puede decirle a git que asuma que no ha cambiado)
5. correr etckeeper init -d /home/username
6. correr git commit -d /home/username
7. configurar alias en su shell para hacer la línea de comando más agradable, como homekeeper checkout

La razón para usar etckeeper es que almacenará metadatos como permisos para sus archivos (bastante importante para ciertas cosas como las claves ssh). Ahora debería tener un enlace previo a la confirmación que guardará los metadatos automáticamente. No estoy tan seguro sobre el pago posterior. Probablemente deberías usar etckeeper checkout xxx -d /home/user, lo investigaré un poco más y elaboraré esta respuesta.

Mi principal problema con el uso de Git en el directorio de inicio es que Git no almacena atributos de archivo como permisos de archivo y marcas de tiempo. Para mí es importante saber cuándo se crearon ciertos archivos, ese puede o no ser el caso para usted. Además, perder permisos para archivos y directorios como .sshes problemático. Entiendo que planeas mantenerte .sshfuera de Git, pero habrá otros lugares donde los permisos pueden ser importantes (como copias de seguridad de sitios web sin comprimir).

Una solución basada en git es especialmente útil si necesita implementar sus archivos en diferentes máquinas, y aún más si tiene partes que son comunes a todas las máquinas y partes que son específicas de algunas máquinas. Puede hacer múltiples repositorios y usar una herramienta como multigit o vcsh para clonarlos en el mismo directorio (su directorio de inicio en este caso).