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

Tue Feb 5 23:19:28 CET 2013

Andrey, te entiendo perfectamente y sí, es la forma en la que "te obliga"
el proceso de los pull-requests. No me termina de convencer, en el sentido
de que me resulta dar vueltas para hacer algo que debería resultar mucho
más sencillo y natural...
En el trabajo acabamos de empezar a usar GitHub, y hasta hace dos días
utilizábamos una herramienta distinta para el proceso de revisión y demás
(Rietveld), de manera que podíamos hacer todos estos tejemanejes en local,
antes de subir nada, lo que me resulta menos engorroso, ya que el remoto
siempre está "limpio"

Pero bueno, supongo que no queda más remedio ;-)

  Jaime

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

2013/2/5 Andrey Antukh <niwi at niwi.be>

> Hola
>
> No voy a discutir mas sobre el tema pero creo que puedo ayudarte en algo.
>
> El 5 de febrero de 2013 22:21, Jaime Buelta <jaime.buelta at gmail.com>escribió:
>
> 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...
>>
>
>
> Hay una excepcion a este caso, usar --force no es tan prohibido como
> crees. Te voy a presentar un caso concreto:
> Cuando trabajas en una funcionalidad, la terminas y la subes.
> Haces pull request. Te señalan mejoras...
> Mientras las corriges se hacen mas commits en el proyecto que estas
> contribuyendo.
> Arreglas esas mejoras.
> Haces rebase del master para que tus commits esten por encima.
> Y ahora que pasa? pues que has reescrito el historico de tu rama, pero es
> un comportamiento absolutamente normal. (lo importante es cuando esos
> comits pasan a master y ahi ya no se toca, pero antes, puedes sobreescribir
> todo lo que quieras)
> Subes tus cambios con --force para que la sobreescritura de tu rama
> tambien este en remoto.
> Te aceptan tu pull request.
> Tu borras la rama local y remota.
>
> Es un funcionamiento normal en colaboracion con muchos proyectos de
> software libre, django concretamente. Y repito ... como tu fork es
> estrictamente para añadir funcionalidad y no es el master oficial, ahi
> literalmente puedes sobreescribir tu historico todo lo que quieras hasta
> conseguir el resultado final y es el que se graba en el repo final.
>
> No se si me he explicado.
>
>
>>
>>   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...
>>
>
>
> Si no te gusta que github haga el comit del merge del pull request, coges
> tu repo, haces fetch directamente del repo del fork y luego haces
> fast-forward de los cambios del fork. De esta manera los comitts se
> incorporan linealmente.
> Una vez hecho eso, haces pull de tu repo y el pull request queda
> automaticamente aceptado y cerrado y sin merge por medio.
>
>
>
>
>>
>>   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
>>>
>>
>>
>> _______________________________________________
>> Madrid mailing list
>> Madrid at lists.es.python.org
>> https://lists.es.python.org/listinfo/madrid
>>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20130205/7ba64a2a/attachment.html>