[Py-MAD] Mercurial vs git (antes: Reunión python-madrid febrero 2013)

Tue Feb 5 22:21:24 CET 2013

Hola:

  Sólo era para hacer una acotación, por algunos comentarios que he oído
sobre git. Lo primero de todo, no he utilizado Mercurial, a pesar de ser
Pythonista irredento. Y el caso es que me gusta mucho utilizar git, y una
de las razones es el hecho de "reescribir la historia"

  A ver, dicho así suena muy tremendo, como machacar lo que se ha hecho
antes, cuando a lo que se refiere es a mantener la historia del control de
versiones limpia y clara (o, al menos intentarlo, claro, la vida es más
complicada).

  El uso típico en git de 'rebase' es, simplemente, poner tus commits
encima del trabajo de tus compañeros, en lugar de añadir otro commit
(merge), que puede ser simplemente ruido. Si he corregido dos bugs, por
ejemplo, en dos commit independientes, no tiene demasiado sentido crear
además otro commit que no añade información.
  Claro, es distinto si estoy trabajando en alguna funcionalidad nueva,
complicada, que es mejor dividir en commits unitarios (p.ej, hacer el
módulo X, commit 1: funcionalidad A, commit 2: funcionalidad B, etc). En
ese caso el merge commit añade información, ya que dice "toda esta rama de
aquí tiene que ver con el módulo X y ahora la añadimos a la rama principal"

  Otra forma de modificar tu historial es hacer commit --amend, para, por
ejemplo, corregir erratas en un commit, o resulta que se te olvidó añadir
un fichero. Todo esto pasa de vez en cuando...
  La opción de hacer un rebase interactivo para "fusionar" varios commits
en uno puede venir bien en algún caso, pero en mi experiencia al menos, es
matar moscas a cañonazos. Funciona mejor intentar hacer commits pequeños y
completos.

  Claro, "reescribir la historia" quiere decir poner cuidado ANTES de
enviar tus cambios al repositorio central. Una vez que los cambios están en
remoto, no se puede (debe) tocar, ya que podrías fastidiar a alguien. Usar
git push --force está casi casi prohibido, salvo casos de fuerza mayor...
Librarse de código en remoto es muy difícil, porque cualquiera que lo tenga
puede volver a subirlo, haciendo posiblemente un merge muy lioso...

  Uno de los problemas que tengo con GitHub es que no permite muy bien este
patrón, ya que TIENES que poner tu código en remoto antes de que nadie
pueda echarle un ojo, y los 'pull requests' son siempre merges, aunque sean
un commit unitario resolviendo un bug. La tendencia es a que el historial
de los proyectos (open source) en GitHub sea un jaleo bastante grande,
difícil de seguir, y a que sea frecuente que haya commits que el código no
funciona de forma obvia, cosa que a mí me da bastante rabia... No sé si hay
una forma mejor de hacerlo, claro... Oye, que me encanta GitHub y funciona
muy bien para promocionar código y para animar a la gente a juguetear y a
tocar el código, pero para lo que es revisión de código y mantener un
historial "limpio", pues no me lo parece...

  En fin, que creo que esa es la filosofía detrás de permitir las
reescrituras de historial en git. A mí también me daba un poco de miedo al
principio, y eso de hacer rebase te pone los pelos de punta al principio.
Pero, a la larga, creo que hace tener un historial más limpio que sirve
para saber cómo evoluciona tu código, lo cual a mí me parece una
herramienta muy útil...

    Jaime

PD: Dejo un artículo muy bueno al respecto (en inglés)
http://blog.izs.me/post/37650663670/git-rebase

---
Check my blog!
http://wrongsideofmemphis.wordpress.com

2013/2/5 Guillermo Vaya <guivaya at gmail.com>

> Es un sistema distribuido...  La opción de tenerlo en 2 o n sitios es
> perfectamente viable y sacar las ventajas de todos
> El 05/02/2013 19:24, "Andrey Antukh" <niwi at niwi.be> escribió:
>
>>
>>
>> El 5 de febrero de 2013 19:13, Kiko <kikocorreoso at gmail.com> escribió:
>>
>>> Bonita charla. Gracias!!!
>>>
>>> Si hay presentación mercurial que alguien la grabe, por favor!!!
>>>
>>> El 5 de febrero de 2013 19:11, Jesus Cea <jcea at jcea.es> escribió:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 05/02/13 19:06, Jesus Cea wrote:
>>>>
>>>> > http://hg.jcea.es/python-es/asociacion/
>>>> >
>>>> > Hay también un repositorio de la web de la PyConES actualmente
>>>> > online, pero no es público (porque no ha hecho falta, no por nada
>>>> > en especial).
>>>> >
>>>> > Puedo crear los repositorios adicionales que sean necesarios, y
>>>> > dar acceso de push a quien haga falta.
>>>>
>>>> Si a alguien le molesta que aparezca mi DNS por ahí, me cuesta poco
>>>> crear un "hg" bajo el dominio es.python.org, aunque me cuesta menos no
>>>> hacerlo :).
>>>>
>>>> Como en mercurial (y GIT), todos los clones son iguales y contienen la
>>>> misma información, incluyendo en el servidor, si mañana desaparezco
>>>> (de este repositorio tengo cuatro backup en cuatro sitios distintos,
>>>> incluyendo un disco duro offline en mi casa), cualquiera con un "clon"
>>>> puede crear un nuevo servidor.
>>>>
>>>> Que el repositorio resida en un servidor propio en vez de algo como
>>>> BitBucket, permite cosas como meter "hooks" para hacer lo que queramos
>>>> en el servidor. Por ejemplo, reconstruir la web cuando se hace un
>>>> commit o se mueve un tag. O lo que se nos ocurra dentro de dos años.
>>>
>>>
>>
>> Losiento, no me gusta la idea, eso supone que la web tambien la vas a
>> alojar tu y en caso contrario ya no nos aporta ventaja.
>> No es visible. La gente busca en github y en bitbucket, y repos propios
>> son mas complicados de encontrar y son menos visibles.
>> La gestion de permisos de acceso son muy simples de gestionar por un
>> servicio tipo github o bitbucket. No me digas que lo tuyo tambien es
>> simple... por que vas a tener que darlos tu... y no cualquiera de los
>> miembros de confianza que administren eso.
>>
>> En fin. No me parece una opcion tenerlo alojado en tus servidores, la
>> opcion mas viable es bitbucket.
>> https://bitbucket.org/pythonspain
>>
>>
>>
>>
>> --
>> Andrey Antukh - Андрей Антух - <niwi at niwi.be>
>> http://www.niwi.be/about.html
>> http://www.kaleidos.net/A5694F/
>>
>> "Linux is for people who hate Windows, BSD is for people who love UNIX"
>> "Social Engineer -> Because there is no patch for human stupidity"
>>
>> _______________________________________________
>> Madrid mailing list
>> Madrid at lists.es.python.org
>> https://lists.es.python.org/listinfo/madrid
>>
>
> _______________________________________________
> Madrid mailing list
> Madrid at lists.es.python.org
> https://lists.es.python.org/listinfo/madrid
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20130205/bcc0a95c/attachment.html>