…. o cómo se puede uno complicar la vida y qué soluciones hay.

Soy de la vieja escuela. Eso significa que mi entorno de trabajo (como programador) emplea herramientas simples y directas.

El editor de textos es Vim pero apenas uso una mínima cantidad de sus posibilidades. Make me sirve como constructor y lanzador de procesos. El depurador de Perl más básico es el que me permite arreglar cosas. Ninguno de ellos lo empleo en toda su capacidad; pero me sirven bien.

Lo malo es cuando tengo que ir de máquina en máquina; hoy, por ejemplo, estoy en casa de mi hija para llevarla al colegio y como tengo una cuenta en su portátil Linux me he puesto a terminar unas bibliotecas de código pendientes (mientras espero que se termine de preparar, que esa es otra). No es difícil traerse una copia del repositorio central; lo complicado es replicar exactamente la configuración del editor, los alias del shell, las particularidades de las conexiones ssh y un buen puñado de detalles más.

Hace tiempo, antes de la aparición de git, tenía un pequeño mecanismo que importaba de una máquina exterior los archivos de configuración (dotfiles en la jerga informática) y los instalaba en los lugares correspondientes. Funcionaba bien pero era una pesadilla para mantener. Tanto que dejé de usarlo y me limitaba a copiar y modificar fragmentos.

Pero ahora mismo me encuentro con que tengo una limitación de tiempo importante para cumplir con un proyecto y varios lugares (hasta cuatro) donde retomar el trabajo y aprovechar un rato. Pues bien, vamos a aprovechar que otros ya han lidiado con lo mismo y a reutilizar (con permiso) su trabajo.

Nicola Paolucci tiene un artículo estupendo que describe un mecanismo para gestionar la configuración personal empleando el programa git con alguna particularidad que desconocía por completo. En su artículo reconoce que se basa en un hilo de Hacker News del usuario StreakyCobray que define como

Sin herramientas adicionales, sin enlaces simbólicos, los archivos los gestiona un sistema de control de versiones; se pueden emplear ramas para diferentes máquinas y replicarlo fácilmente en una instalación nueva.

La técnica consiste en emplear git de una manera bastante ingeniosa: un repositorio desnudo (bare repository) para conservar los cambios y como directorio de trabajo usar el directorio de trabajo del usuario ($HOME). Después, con un alias específico se crea una herramienta concreta para emplear con el mantenimiento.

$ git init --bare $HOME/.cfg
$ alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
$ config config --local status.showUntrackedFiles no

El alias config debe estar registrado en la configuración del shell para que éste funcione siempre aśi que hacemos además lo siguiente:

$ echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc

Ahora las posibilidades son muchas, tantas como un repositorio git nos permite con otro tipo de archivos. Podemos añadir la configuración de ssh a su control, crear una rama para una máquina concreta, y, si le añadimos un servidor remoto como localización central tendremos siempre la misma configuración disponible a golpe de clonado.

El autor recomienda también crear un pequeño script que nos permita descargar y poner en marcha todo el mecanismo en cualquier máquina nueva. Algo que he hecho antes con los repositorios de paquetes y que ha demostrado ser muy práctico.

Y ya para terminar de hablar de ello, en el artículo se muestra el procedimiento para integrar este mecanismo en un sistema ya en marcha, realizando copias de aquellos archivos de configuración que puedan verse afectados.

Muy recomendable por su limpieza y su sencillez.