<div dir="ltr">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...<div>
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"<br>
<div><br></div><div style>Pero bueno, supongo que no queda más remedio ;-)</div><div style><br></div><div style> Jaime</div></div></div><div class="gmail_extra"><br clear="all"><div>---<br>Check my blog!<br><a href="http://wrongsideofmemphis.wordpress.com">http://wrongsideofmemphis.wordpress.com</a></div>
<br><br><div class="gmail_quote">2013/2/5 Andrey Antukh <span dir="ltr"><<a href="mailto:niwi@niwi.be" target="_blank">niwi@niwi.be</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hola<br><div class="gmail_extra"><br></div><div class="gmail_extra">No voy a discutir mas sobre el tema pero creo que puedo ayudarte en algo.<br><br><div class="gmail_quote">El 5 de febrero de 2013 22:21, Jaime Buelta <span dir="ltr"><<a href="mailto:jaime.buelta@gmail.com" target="_blank">jaime.buelta@gmail.com</a>></span> escribió:<div class="im">
<br>
<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">Hola:<div><br></div><div> 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"</div>
<div><br></div><div> 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).</div>
<div><br></div><div> 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.</div>
<div> 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"</div>
<div><br></div><div> 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...</div>
<div> 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.<br>
</div><div><br></div><div> 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...</div>
</div></blockquote><div><br></div><div><br></div></div><div>Hay una excepcion a este caso, usar --force no es tan prohibido como crees. Te voy a presentar un caso concreto:</div><div>Cuando trabajas en una funcionalidad, la terminas y la subes.</div>
<div>Haces pull request. Te señalan mejoras...</div><div>Mientras las corriges se hacen mas commits en el proyecto que estas contribuyendo.</div><div>Arreglas esas mejoras.</div><div>Haces rebase del master para que tus commits esten por encima.</div>
<div>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)</div>
<div>Subes tus cambios con --force para que la sobreescritura de tu rama tambien este en remoto.</div><div>Te aceptan tu pull request.</div><div>Tu borras la rama local y remota.</div><div><br></div>
<div>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.</div>
<div><br></div><div>No se si me he explicado.</div><div class="im"><div> </div><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><br></div><div> 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...</div>
</div></blockquote><div> </div><div><br></div></div><div>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.</div>
<div>Una vez hecho eso, haces pull de tu repo y el pull request queda automaticamente aceptado y cerrado y sin merge por medio.</div><div><div class="h5"><div><br></div><div><br></div><div> </div><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><br></div><div> 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...</div>
<div><br></div><div> Jaime</div><div><br></div><div>PD: Dejo un artículo muy bueno al respecto (en inglés) <a href="http://blog.izs.me/post/37650663670/git-rebase" target="_blank">http://blog.izs.me/post/37650663670/git-rebase</a></div>
</div><div class="gmail_extra"><br clear="all"><div>---<br>Check my blog!<br><a href="http://wrongsideofmemphis.wordpress.com" target="_blank">http://wrongsideofmemphis.wordpress.com</a></div><div><div>
<br><br><div class="gmail_quote">2013/2/5 Guillermo Vaya <span dir="ltr"><<a href="mailto:guivaya@gmail.com" target="_blank">guivaya@gmail.com</a>></span><br><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">
<p dir="ltr">Es un sistema distribuido... La opción de tenerlo en 2 o n sitios es perfectamente viable y sacar las ventajas de todos</p>
<div class="gmail_quote">El 05/02/2013 19:24, "Andrey Antukh" <<a href="mailto:niwi@niwi.be" target="_blank">niwi@niwi.be</a>> escribió:<br type="attribution"><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><div>
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">El 5 de febrero de 2013 19:13, Kiko <span dir="ltr"><<a href="mailto:kikocorreoso@gmail.com" target="_blank">kikocorreoso@gmail.com</a>></span> escribió:<br>
<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">Bonita charla. Gracias!!!<br><br>Si hay presentación mercurial que alguien la grabe, por favor!!!<br>
<br><div class="gmail_quote">El 5 de febrero de 2013 19:11, Jesus Cea <span dir="ltr"><<a href="mailto:jcea@jcea.es" target="_blank">jcea@jcea.es</a>></span> escribió:<div><div><br>
<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>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div>On 05/02/13 19:06, Jesus Cea wrote:<br>
<br>
> <a href="http://hg.jcea.es/python-es/asociacion/" target="_blank">http://hg.jcea.es/python-es/asociacion/</a><br>
><br>
> Hay también un repositorio de la web de la PyConES actualmente<br>
> online, pero no es público (porque no ha hecho falta, no por nada<br>
> en especial).<br>
><br>
> Puedo crear los repositorios adicionales que sean necesarios, y<br>
> dar acceso de push a quien haga falta.<br>
<br>
</div>Si a alguien le molesta que aparezca mi DNS por ahí, me cuesta poco<br>
crear un "hg" bajo el dominio <a href="http://es.python.org" target="_blank">es.python.org</a>, aunque me cuesta menos no<br>
hacerlo :).<br>
<br>
Como en mercurial (y GIT), todos los clones son iguales y contienen la<br>
misma información, incluyendo en el servidor, si mañana desaparezco<br>
(de este repositorio tengo cuatro backup en cuatro sitios distintos,<br>
incluyendo un disco duro offline en mi casa), cualquiera con un "clon"<br>
puede crear un nuevo servidor.<br>
<br>
Que el repositorio resida en un servidor propio en vez de algo como<br>
BitBucket, permite cosas como meter "hooks" para hacer lo que queramos<br>
en el servidor. Por ejemplo, reconstruir la web cuando se hace un<br>
commit o se mueve un tag. O lo que se nos ocurra dentro de dos años.</blockquote></div></div></div></blockquote><div><br></div><div><br></div><div>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.</div>
<div>No es visible. La gente busca en github y en bitbucket, y repos propios son mas complicados de encontrar y son menos visibles.</div><div>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.</div>
<div><br></div><div>En fin. No me parece una opcion tenerlo alojado en tus servidores, la opcion mas viable es bitbucket.</div><div><a href="https://bitbucket.org/pythonspain" target="_blank">https://bitbucket.org/pythonspain</a></div>
<div><br></div><div> <br></div></div><br clear="all"><div><br></div>-- <br>Andrey Antukh - Андрей Антух - <<a href="mailto:niwi@niwi.be" target="_blank">niwi@niwi.be</a>><br><a href="http://www.niwi.be/about.html" target="_blank">http://www.niwi.be/about.html</a><br>
<a href="http://www.kaleidos.net/A5694F/" target="_blank">http://www.kaleidos.net/A5694F/</a><br><br>"Linux is for people who hate Windows, BSD is for people who love UNIX"<br>"Social Engineer -> Because there is no patch for human stupidity"
</div></div>
<br></div></div><div>_______________________________________________<br>
Madrid mailing list<br>
<a href="mailto:Madrid@lists.es.python.org" target="_blank">Madrid@lists.es.python.org</a><br>
<a href="https://lists.es.python.org/listinfo/madrid" target="_blank">https://lists.es.python.org/listinfo/madrid</a><br></div></blockquote></div>
<br>_______________________________________________<br>
Madrid mailing list<br>
<a href="mailto:Madrid@lists.es.python.org" target="_blank">Madrid@lists.es.python.org</a><br>
<a href="https://lists.es.python.org/listinfo/madrid" target="_blank">https://lists.es.python.org/listinfo/madrid</a><br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Madrid mailing list<br>
<a href="mailto:Madrid@lists.es.python.org" target="_blank">Madrid@lists.es.python.org</a><br>
<a href="https://lists.es.python.org/listinfo/madrid" target="_blank">https://lists.es.python.org/listinfo/madrid</a><br></blockquote></div></div></div><div><div class="h5"><br><br clear="all"><div><br></div>-- <br>Andrey Antukh - Андрей Антух - <<a href="mailto:niwi@niwi.be" target="_blank">niwi@niwi.be</a>><br>
<a href="http://www.niwi.be/about.html" target="_blank">http://www.niwi.be/about.html</a><br><a href="http://www.kaleidos.net/A5694F/" target="_blank">http://www.kaleidos.net/A5694F/</a><br><br>"Linux is for people who hate Windows, BSD is for people who love UNIX"<br>
"Social Engineer -> Because there is no patch for human stupidity"
</div></div></div></div>
<br>_______________________________________________<br>
Madrid mailing list<br>
<a href="mailto:Madrid@lists.es.python.org">Madrid@lists.es.python.org</a><br>
<a href="https://lists.es.python.org/listinfo/madrid" target="_blank">https://lists.es.python.org/listinfo/madrid</a><br></blockquote></div><br></div>