[Py-MAD] Mercurial y GIT

[J. Javier Maestro]

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

>
>> Solo tengo una pega a esto. Es mercurial es que aveces va a matacaballo
> para parecerse a git.
> Y si te refieres al hecho de que en mercurial la historia es inmutable,
> eso es una escusa absurda
> cuando en la charla se ha quedado muy claro que si es mutable, aun siendo
> ligeramente mas complicado
> mutarla que en git :D
>
> Mercurial solo te pone trabas! No te imposibilita como bien dijiste!
>

No sólo es así, sino que, si entendí bien el flujo de trabajo que sigue
Jesús en cpython (moviendo código/parches entre clones distintos, etc):

 - Es exactamente lo que git hace por defecto mediante ramas, pero
haciéndolo complejo/difícil/error prone, IMHO.
 - No preservas la historia *para nada*. Es decir, no preservas más
historia que la que quieres preservar... como pasa con git.

Lo de "preservar la historia" creo que ha quedado patente que es falso.
Ambos te permiten modificarla (el que sea difícil no vale, vete a decirle a
ese juez que nombraba Jesús que "Señoría, esto es totalmente válido porque
yo no lo sé tocar!"), por lo que este argumento no vale. El 99% de las
discusiones de la "historia" que he visto en esta lista están basadas en
miedos de hacer burradas que NADIE hace en la vida real con un arbol
PÚBLICO! Si es un arbol privado... qué mas da lo que hagas con la
historia!?? Quiero algo que me deje hacer lo que me da la gana y no me
complique la vida.

Ahora, si vamos a hablar de la porcelana / CLI, etc... yo he usado
Mercurial unos 6 años y git como año y medio, aproximadamente. Al argumento
de que Mercurial es "más limpio", "coherente", como lo queráis llamar... yo
estoy de acuerdo. Pero vamos... que en git, la porcelana *ahora* no está
tan mal, ni de lejos!

Por tanto, a mi entender, los únicos argumentos a favor de Mercurial son:

 - Está hecho en Python: y este argumento, "a medias". Porque las mayores
contribuciones y el ecosistema se consigue... con plugins y API. Y se les
debería caer la cara de vergüenza absoluta cuando te dicen que la "API" es
la linea de comandos. Vaya pythonistas están hechos... ni un wrapper son
capaces de darte para que construyas buenos plugins sin tener que andar
parseando lo que te escupen comandos. Ya puestos, puedes hacer plugins para
mercurial en Ruby. Total, con llamar a los comandos de mercurial ya vas
listo!

- Si estás obligado a trabajar en Windows, porque Mercurial es portable.
Aunque (y aquí hablo desde el total desconocimiento) creo que git ya rula
en Windows (eso pone en su página de Wikipedia, pero no lo sé, llevo sin
tocar un Windows la tira de años...)

Ah, y el argumento del flow... señores, el flow, por definición, es un
convenio entre los desarrolladores que lo usan. Ni mercurial ni git tienen
"buen flow", ni existe ese "flow de mercurial" que te ayuda con proyectos
OSS que usan mercurial a los que llegas de novato. Cada proyecto es un
mundo y le gusta las contribuciones a su manera. Así que, a mi entender,
gana este "flow" la herramienta que sea más moldeable y fácilmente
adaptable sin hacer daño. Y, en este caso, gana **de calle** git y su
concepto de "staging area". Si lo "ignoras" y lo usas simplemente como un
paso previo a commit, allá tu. Pero si lo entiendes, sí que te permite
mejorar ese "flow" que una mayoría de desarrolladores llama "bueno". Este y
otros detallitos es lo que hace que git gane, IMHO, de calle a la hora de
trabajar con grandes equipos de desarrolladores. Se puede hacer con los
dos, pero con git ganas en bastantes cosas que mercurial no te da.


En cualquier caso, sinceramente, me toca un pie lo que se use siempre que
los repos de la Asociación sean públicos y estén alojados en un BB / GH.

Saludos,

-- 
jj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20130303/a2dacd08/attachment.html>