<div dir="ltr">2013/3/2 Andrey Antukh <span dir="ltr"><<a href="mailto:niwi@niwi.be" target="_blank">niwi@niwi.be</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br></blockquote><div><span style="color:rgb(34,34,34)">Solo tengo una pega a esto. Es mercurial es que aveces va a matacaballo para parecerse a git.</span><br></div></div></div><div>Y si te refieres al hecho de que en mercurial la historia es inmutable, eso es una escusa absurda</div>

<div>cuando en la charla se ha quedado muy claro que si es mutable, aun siendo ligeramente mas complicado</div><div>mutarla que en git :D</div><div><br></div><div>Mercurial solo te pone trabas! No te imposibilita como bien dijiste! </div>
</div></div></div></blockquote><div><br></div><div style>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):</div><div style><br>
</div><div style> - Es exactamente lo que git hace por defecto mediante ramas, pero haciéndolo complejo/difícil/error prone, IMHO.</div><div style> - No preservas la historia *para nada*. Es decir, no preservas más historia que la que quieres preservar... como pasa con git.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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!</div>
<div style><br></div><div style>Por tanto, a mi entender, los únicos argumentos a favor de Mercurial son:</div><div style><br></div><div style> - 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!</div>
<div style><br></div><div style>- 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...)<br>
</div><div style><br></div><div style>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.</div>
<div style><br></div><div style><br></div><div style>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.</div><div style><br></div>
<div style>Saludos,</div><div style><br></div><div style>-- </div><div style>jj</div></div>
</div></div>