…. o c\u00f3mo se puede uno complicar la vida y qu\u00e9 soluciones hay.<\/p>\n
<\/p>\n
Soy de la vieja escuela. Eso significa que mi entorno de trabajo (como programador) emplea herramientas simples y directas.<\/p>\n
El editor de textos es Vim<\/em> pero apenas uso una m\u00ednima cantidad de sus posibilidades. Make<\/em> me sirve como constructor y lanzador de procesos. El depurador de Perl<\/em> m\u00e1s b\u00e1sico es el que me permite arreglar cosas. Ninguno de ellos lo empleo en toda su capacidad; pero me sirven bien.<\/p>\n Lo malo es cuando tengo que ir de m\u00e1quina en m\u00e1quina; hoy, por ejemplo, estoy en casa de mi hija para llevarla al colegio y como tengo una cuenta en su port\u00e1til Linux me he puesto a terminar unas bibliotecas de c\u00f3digo pendientes (mientras espero que se termine de preparar, que esa es otra). No es dif\u00edcil traerse una copia del repositorio central; lo complicado es replicar exactamente la configuraci\u00f3n del editor, los alias del shell<\/em>, las particularidades de las conexiones ssh<\/em> y un buen pu\u00f1ado de detalles m\u00e1s.<\/p>\n Hace tiempo, antes de la aparici\u00f3n de git<\/em>, ten\u00eda un peque\u00f1o mecanismo que importaba de una m\u00e1quina exterior los archivos de configuraci\u00f3n (dotfile<\/em>s<\/em> en la jerga inform\u00e1tica) y los instalaba en los lugares correspondientes. Funcionaba bien pero era una pesadilla para mantener. Tanto que dej\u00e9 de usarlo y me limitaba a copiar y modificar fragmentos.<\/p>\n Pero ahora mismo me encuentro con que tengo una limitaci\u00f3n 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.<\/p>\n Nicola Paolucci<\/a> tiene un art\u00edculo<\/a> estupendo que describe un mecanismo para gestionar la configuraci\u00f3n personal empleando el programa git<\/em> con alguna particularidad que desconoc\u00eda por completo. En su art\u00edculo reconoce que se basa en un hilo de Hacker News<\/a> del usuario Sin herramientas adicionales, sin enlaces simb\u00f3licos, los archivos los gestiona un sistema de control de versiones; se pueden emplear ramas para diferentes m\u00e1quinas y replicarlo f\u00e1cilmente en una instalaci\u00f3n nueva.<\/p>\n La t\u00e9cnica consiste en emplear git<\/em> de una manera bastante ingeniosa: un repositorio desnudo (bare repository<\/em>) para conservar los cambios y como directorio de trabajo usar el directorio de trabajo del usuario ($HOME<\/em>). Despu\u00e9s, con un alias espec\u00edfico se crea una herramienta concreta para emplear con el mantenimiento.<\/p>\n El alias config<\/em> debe estar registrado en la configuraci\u00f3n del shell<\/em> para que \u00e9ste funcione siempre a\u015bi que hacemos adem\u00e1s lo siguiente:<\/p>\n Ahora las posibilidades son muchas, tantas como un repositorio git<\/em> nos permite con otro tipo de archivos. Podemos a\u00f1adir la configuraci\u00f3n de ssh<\/em> a su control, crear una rama para una m\u00e1quina concreta, y, si le a\u00f1adimos un servidor remoto como localizaci\u00f3n central tendremos siempre la misma configuraci\u00f3n disponible a golpe de clonado.<\/p>\nStreakyCobra<\/code>y que define como<\/p>\n$ git init --bare $HOME\/.cfg\r\n$ alias config='\/usr\/bin\/git --git-dir=$HOME\/.cfg\/ --work-tree=$HOME'\r\n$ config config --local status.showUntrackedFiles no\r\n\r\n<\/pre>\n
$ echo \"alias config='\/usr\/bin\/git --git-dir=$HOME\/.cfg\/ --work-tree=$HOME'\" >> $HOME\/.bashrc<\/pre>\n