[Py-MAD] Mercurial y GIT

[Jose Luis]

Indiscutiblemente rebases y squash sistemáticos indican que estás loco.

Comparto que algunos de los comandos de git, no son muy intuitivos ;-P

Los interfaces gráficos de git (git-gui y gitk) me parecen muy sencillos,
pero muy correctos.
No tratan de facilitar demasiado ocultando y despistando.
Sólo los utilizo para ver la historia y ramas, y para revisar antes de un
commit o merge.
Sé que tienen muchas más opciones, pero me sobran.

Para todo lo demás, la consola con autocompletar, es lo más eficaz.

Cuando trabajo en mi rama local, me gusta poder hacer pequeños cambios en
la historia.
Para limpiar, o para corregir alguna tontería del último comit  (soy muy
humano).

En muy pocos casos se pude justificar un cambio en la historia pública.
Pero aunque git lo permita...

1.- No permite hacerlo por error
2.- No habrá destrucción de información
3.- Se detectará rápidamente

El punto 1, evita argumentos atenuantes ante el juez.
El punto 2, nos permite recuperar la situación fácilmente.
Y el tercero, nos permitirá tomar medidas disuasorias de forma inmediata
(generalmente colgándole de los dedos de los pies unas horillas para que
reflexione sobre el sentido de la vida y esas cosas...)


Me gusta la libertad que da git y lo sencillo de sus conceptos.
Pero eso también te deja sólo y desnudo cuando empiezas. ¿Cómo organizarme?
¿Qué flujo de trabajo utilizar?

Con buena voluntad puedes mirar en internet y encontrarte con varios tipos
de workflow
http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
http://nvie.com/posts/a-successful-git-branching-model/


Yo hago cosas más sencillas y me complico mucho menos la vida, y para
empezar... asusta

Por algo surgirán herramientas como... https://github.com/nvie/gitflow?
http://yakiloo.com/getting-started-git-flow/


¿Y que tal las estrategias de merge?

https://www.kernel.org/pub//software/scm/git/docs/git-merge.html
resolve, recursive (ours, theirs, patience, ignore-space-change,
renormalize, rename-threshold, subtree, ...), octopus, ours, subtree

Es mucho para mi.



En cualquier caso me parece muy coherente utilizar mercurial si eres de
python.

Mercurial es un gran sistema de control de versiones distribuido,
desarrollado en python!!!


2013/3/1 piranna at gmail.com <piranna at gmail.com>

> Ningun programa o protocolo lleva en su ADN el como debe de ser la
> interfaz a no ser que este diseñado de pena (se me vienen a la cabeza
> multitud de aplicaciones chorras de VisualBasic... :-P). Tu si quieres, te
> puedes coger libGit y hacerte tu propio cliente en linea de comandos para
> dummies siendo totalmente compatible. Una cosa es el core de la aplicacion,
> el formato y el protocolo, y otra es la interfaz de usuario... y lo que
> digo que en este ultimo punto todas fallan, tanto CLI como graficas, pero
> Git, como protocolo y core, es a mi opinion el versionado de codigo mas
> potente.
>
> Sent from my Android cell phone, please forgive the lack of format on the
> text, and my fat thumbs :-P
> El 01/03/2013 15:27, "Jaime Buelta" <jaime.buelta at gmail.com> escribió:
>
> *git no está pensado para ser usado con aplicaciones gráficas.* En su ADN
>> está muy metido el tema de línea de comandos, así que, bajo mi punto de
>> vista, las aplicaciones gráficas no ayudan demasiado a hacer operaciones
>> complicadas.
>>
>> Y es verdad que los comandos son complicados... Es el tema línea de
>> comandos, con 300 parámetros distintos y nomenclatura nada evidente al
>> máximo exponente...
>>
>> Yo ya me he acostumbrado, y me han designado varias veces "el experto en
>> la sala de git", pero soy totalmente consciente de lo mucho que me costó
>> hacerme a muchas cosas... No es una herramienta fácil para nada...
>>
>>   Jaime
>>
>> ---
>> Check my blog!
>> http://wrongsideofmemphis.wordpress.com
>>
>>
>> 2013/3/1 piranna at gmail.com <piranna at gmail.com>
>>
>>> > De esa manera, es más difícil de corromper que "reconstruir" un
>>> fichero de texto a base de diffs
>>>
>>> Y por eso es el unico repositorio que todavia no me he cargado o que
>>> he conseguido recuperarlo (aunque fuera a las malas copiando a mano
>>> los archivos de nuevo en el directorio de trabajo) sin que me corriera
>>> ni una gota de sudor por la frente como me ha pasado con CVS, SVN y
>>> hg... :-P La unica pega que le veo a Git es que para trabajar a bajo
>>> nivel los comandos no son nada claros y se hace demasiado complicado y
>>> lioso, y ni siquiera las aplicaciones graficas ayudan... :-/
>>>
>>>
>>> --
>>> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
>>> monton de sitios diferentes, simplemente escribe un sistema operativo
>>> Unix."
>>> – Linus Tordvals, creador del sistema operativo Linux
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20130302/3280794a/attachment.html>