Hasta ahora mi trabajo con git ha sido bastante plano y simple. Es decir, aunque lo he utilizado en muchas de mis cosas, mis repositorios apenas tienen ramas. Por ejemplo, la contabilidad, que la llevo con Ledger-Cli, ya lo conté por aquí, tiene un repositorio git donde voy actualizando los gastos y las facturas. Sin embargo, no hay ramas, es un repositorio unipersonal muy sencillo: git commit, git push y nada más.

Este blog también tiene su repositorio. Vale que tengo una rama para borradores de artículos y la principal para publicarlos. Pero también es un repositorio unipersonal y lineal: las ramas no se mezclan, no se cruzan, hay dos ramas: una para escribir y otra para publicar. No hay rebasado ni mezcla entre ellas.

El utilizar git para programar, en un repositorio compartido y con una profusión de ramas a la que no estoy acostumbrado, me está obligando a aprender cómo funciona git en realidad, con un ejemplo concreto de lo que es un repositorio de desarrollo. Me obliga a aprender a hacer rebases y merges.

Redescubrir git implica que estoy redescubriendo también magit. Todo lo que aprendo nuevo lo hago desde la línea de comandos. Eso me permite con posterioridad hacerlo desde magit con más conocimiento de causa. Desde el buffer de magit-status se pueden lanzar un montón de comandos pulsando una sola tecla: commit, pull, fetch, push, rebase, merge, log...

También, me he encontrado algún problema. Es decir, no problemas por mal funcionamiento de las herramientas sino por despiste del usuario: como estar convencido de estar en una determinada rama y estar en otra. Eso me recuerda que siempre, cada vez que voy a realizar alguna acción tengo que pulsar C-c g, ─la combinación de teclas para el comando magit-status que tengo asignada─, y comprobar que efectivamente estoy en la rama que debo estar antes de hacer un merge o un rebase.

Hasta ahora tenía instalado Projectile para la gestión de proyectos, pero apenas lo utilizaba. Tampoco es que haya dando un salto cuantitativo con él, creo que apenas lo utilizo un mínimo porcentaje de toda su funcionalidad, tan sólo estoy utilizando unos pocos comandos con profusión y con el nuevo proyecto le he encontrado alguna función interesante:

• Compilar: C-c p c. El proyecto cuenta con un Makefile que hace todo el trabajo, incluso con un comando make run que compila y lanza el proyecto de forma automática, pero lo veremos después. Le puedes decir a Projectile que lo utilice en lugar del escueto make. Si hay errores, en la ventana de compilación puedes navegar por los errores de forma sencilla para solucionarlos.
• Buscar en el proyecto: C-c p s g. Busca una expresión en todo el proyecto. Bueno, esto lo utilizo más cuando escribo en el blog, porque me permite buscar en todos los ficheros y saltar al que me interesa desde la lista de resultados.
• Abrir fichero: C-c p f. Muestra una lista de ficheros que pertenecen al proyecto y es más fácil buscar el que te interesa, al menos en proyectos pequeños, que navegando con Dired.
• Ejecutar el proyecto: C-c p u. La primera vez que lo llamas pide el comando para iniciarlo. En este caso make run, luego cada vez que lo quiero lanzar es suficiente con la combinación de teclas. Hay que tener en cuenta que en esta ocasión lanza también un entorno erlang y que hay que pararlo para hacer más pruebas.
• Cerrar los buffers del proyecto: C-c p k. Hace un kill de los buffers abiertos del proyecto. Algo que me viene muy bien porque suelo utilizar emacs en su modo daemon. Cuando cierras la ventana de emacs los buffers siguen abiertos, por lo que cambiar de actividad, pasar de un proyecto a otro puede sobrecargar el editor con demasiados buffers abiertos. Cerrar de forma selectiva un grupo de ellos es muy útil.

Cuando comencé con el erlang me pareció un lenguaje muy marciano. Bueno, sigue pareciéndomelo, no es comparable a otros lenguajes que conozco y tiene una sintaxis un tanto extraña.

Después de varias semanas trabajando con él me encuentro cómodo y poco a poco mis esquemas mentales se van adaptando a otra forma de pensar y hacer las cosas.

Un problema con el que me he encontrado es con el indentado, ya sabéis lo especial que es emacs con los indentados, precisamente porque delega en los modos este aspecto, resulta un poco caótico. Depende de los gustos de quien haya programado el modo. No siempre esos gustos coinciden con todo el mundo.

Concretamente, me estoy acostumbrando a no utilizar TAB para realizar la indentación, porque lo hará al modo establecido en erlang.el y sí a utilizar M-i que, tiendo tab-width establecido a 4 espacios, realiza la identación sin llamar a lo establecido en el modo y haciendo los saltos de cuatro en cuatro espacios.