El viernes pasado (19 de abril de 2013) Jesús Espino dio una charla titulada «Git internals» en Kaleidos. Lo primero que es digno de mención es que una empresa de una «charla interna» e invite a cualquiera que quiera asistir «de fuera». Iniciativas como esta deberían estar a la orden del día en empresas en todo nuestro país. Desde aquí animo a cualquier colega de profesión, trabaje donde trabaje (cárnicas, startups o lo que se tercie) a que comparta lo que sabe, bien sea en un blog, dando charlas en grupos locales o imitando este tipo de iniciativas aunque sea internamente dentro de su empresa. «Hay que subir el nivel» como dice Diego Freniche. Y como me gusta repetirme a mi mismo todos los días: «si quieres cambiar las cosas, empieza cambiando tú y tu entorno».
La charla, que está escrita en TeX, podéis encontrarla en github. Independientemente de los recuerdos que me trajo ver el código fuente (la tesis la escribí en LaTeX) el contenido de la misma no tiene desperdicio. Si os interesa el tema, aunque sea árido, y queréis profundizar en él os recomiendo que leáis el capítulo 9 del libro de Scott Chacon.
Durante la charla se habló bastante de las referencias. Cuando Jesús acabó su magistral intervención, comenté un pequeño truco que aprendí en twitter para poder descargarnos a nuestra máquina los pull requests que recibimos desde github. Llevaba tiempo queriendo sacar un rato para contarlo y Jesús me dio el empujón que me faltaba.
Accediendo a los pull requests
En este artículo usaremos como base el repositorio que utilizamos para la serie de artículos sobre pull requests.
Cuando un usuario hace un pull request desde su fork al repositorio original, github crea en el repositorio orignal una referencia a los commits cuya incorporación se ha solicitado. El repositorio original, el que recibe el pull request, guarda estas referencias en refs/pull/*/head. Recordad que las referencias en git no son más que ficheros que contienen hashes a objetos de git. Estos ficheros están en los servidores de github.
Para poder acceder a esas referencias, y por lo tanto a esos commits, lo único que hay que hacer es decirle a git que se descargue los ficheros con las referencias cuando ejecutamos el comando fetch. Para ello, abrimos el fichero .git/config de nuestro repositorio y modificamos la sección correspondiente al remoto «origin», añadiendo la línea en cursiva que os pongo a continuación:
[remote "origin"] url = https://github.com/aprendegit/fork fetch = +refs/heads/*:refs/remotes/origin/* fetch = +refs/pull/*/head:refs/remotes/origin/pr/*/head
Antes de ejecutar git-fetch, veamos cómo están las referencias remotas del repositorio en SourceTree:
Referencias remotas antes de importar los pull-requests
Hagamos un fetch:
$ git fetch From https://github.com/aprendegit/fork * [new ref] refs/pull/1/head -> origin/pr/1/head * [new ref] refs/pull/2/head -> origin/pr/2/head * [new ref] refs/pull/3/head -> origin/pr/3/head
¡Ahí las tenéis! Si actualizáis la pantalla de SourceTree:
El repositorio después de hacer fetch de los pull requests
En la captura podéis ver los dos pull requests que ha recibido el proyecto y cómo ha evolucionado cada uno de ellos.
¿Y esto para qué sirve? Pues para probar el código que estáis recibiendo antes de aceptar el pull request, por ejemplo.
Para terminar, quería dar las gracias de nuevo a Jesús por su charla, a Kaleidos por la iniciativa y a Bert Belder (piscisaureus) por colgar el gist con la información que ha dado pie a este artículo.