¿Hay algún command dañino usando GIT y HG?

Estoy enseñando HG a mis alumnos, ya que es un buen playskool DVCS (no tan poderoso como GIT pero simple para empezar a trabajar con conceptos triviales). Uso HG porque parece muy difícil destruir las inputs anteriores (con la exception de hg rollback ), por lo que siempre tienes la posibilidad de volver al tren sin destruir datos importantes. Pero recientemente me preguntaba:

  • es verdad ?
  • GIT ofrece la misma protección (lo leí en algún lado sobre la opción de rebase , que puede ser muy peligrosa)

Ambos son DVCS, lo que significa que se supone que debe clonar el repository y enviar sus cambios a algún lugar cuando desee una copy de security. Si hace esto diligentemente, entonces no tiene importancia qué herramientas destructivas están disponibles para usted, ya que las copys de security son económicas y fáciles de mantener.

Ahora, ten en count que soy un fanático de Git 100% parcial.

Fuera de la caja, Mercurial solo se envía con un command destructivo, rollback. Todo lo demás queda relegado a extensiones que deben habilitarse manualmente: strip, rebase, etc. Estas extensiones son sin duda destructivas ya que reescriben el historial in situ o lo destruyen . Para evitar el uso de estos, la mayoría de los usuarios de Mercurial prefieren usar la extensión Mercurial Queues, que le permite mantener los sets de cambios como parches flexibles antes de configurarlos en piedra como commits. Esto básicamente equivale a un VCS completo que se sienta encima de Mercurial. Hace el trabajo, pero debe aplicarse conscientemente antes de escribir los compromisos.

Por el contrario, Git incluye varios commands que pueden considerarse "destructivos", pero con una diferencia crucial: nunca se reescribe nada dentro de la database de Git. Siempre que utilice los commands rebase, filter-branch o reset, se crean nuevos objects en la database y luego se actualiza el puntero de la twig para señalarlos. Cada vez que se actualiza un puntero de bifurcación, se agrega una input a su reflog, un logging de historial que se encuentra en la parte superior de Git y protege los pointers de sucursal de las actualizaciones no deseadas; siempre es posible revertir un command "destructivo". De hecho, puede ser difícil eliminar permanentemente un object de la database de Git: implica dejar caer la input de reflog y luego podar los objects no resueltos.

En breve:

  • Mercurial es seguro por defecto, pero agregar motosierras puede romperlo por completo.
  • Git está construido con motosierras desde cero, lo que aumenta el peligro aparente, pero hay dispositivos de security.

Para su caso de uso de la enseñanza, estas diferencias son generalmente irrelevantes de todos modos: usted enseñará los commands básicos, y si alguien quiere explorar, la única forma en que aprenderá es quitándole el arm a la cadena. Se dice que Mercurial es más fácil de aprender para los principiantes, pero creo que eso se debe principalmente a que no expone el índice, por lo que se parece más a Subversion. Los neófitos completos para el control de versiones podrían no beneficiarse de esta similitud.

No creo que "playskool" sea un buen término para describir a Mercurial. Es un DVCS importante y con todas las funciones utilizado por Python, OpenOffice, Netbeans y muchos más proyectos . 'Playskool' implica que no está listo para el uso a nivel de producción, o que es una versión diluida de otra cosa. Ambos falsos. Intenta no confundir usabilidad con simplicidad o insignificancia.

Varios miembros han mencionado que, por defecto, Hg no viene con extensiones instaladas, pero como las extensiones son tan fáciles de instalar, podría valer la pena saber cuáles pueden causar algún "daño". Por supuesto, incluso si el daño es causado, la naturaleza distribuida de Hg le permitiría despojar a los sets de cambios ofensivos y volver a tirar de un server centralizado (algo así como cortar y volver a crecer una extremidad cuando lo piense).

También me gustaría diferenciar entre Daño (corrupción del repository o pérdida de datos) y Peligro (HG trampa o acción imprudente – sin pérdida de datos).

Rebase

Daño: Usar rebase podría causar conflictos de fusión severos si estás tratando de volver a establecer la base de revA a revB y son significativamente diferentes. En estos casos, Mercurial generará files .diff que le permitirán manejar usted mismo las fusiones fallidas. Si esto ocurre, la fusión puede ser compleja y los datos podrían perderse.

Peligro: la rebase cambia la identificación hash de cada set de cambios que mueve, lo que significa que no se debe usar una vez que se ha insertado un set de cambios. Además, rebase aplicará sets de cambios a la twig pnetworkingeterminada a less que especifique lo contrario con --keep-branches

Histedit

Daño: aunque mq es probablemente una extensión mejor, histedit todavía se puede usar para reorderar, modificar o editar sets de cambios existentes. El uso de la edit permite a cualquier usuario modificar la revisión, incluso revertir todos los cambios. El uso de drop permite que los sets de cambios se eliminen por completo. Ambas operaciones pueden provocar la pérdida de datos.

Peligro: similar a rebase, histedit puede modificar el hash ID de un set de cambios.

Colas mercuriales (mq)

Daño: Mq es una característica muy poderosa y multifacética, por lo que el daño que puede causar es variado. mq strip es un ejemplo fácil de pérdida potencial de datos.

Peligro: nuevamente, causa cambios de ID.

Retroceder

Como mencionaste, esta operación puede causar algún daño. El text de ayuda lo dice mejor:

Este command debe usarse con cuidado. Solo hay un nivel de reversión, y no hay forma de deshacer una reversión. También restaurará el estado del directory en el momento de la última transacción, perdiendo cualquier cambio de estado del directory desde ese momento.

¿Solución?

Hacer un clon de security antes de usar cualquiera de estas opciones debería permitirle superar incluso el daño catastrófico. ¡Confíe en el hecho de que Hg es un DVCS para garantizar que siempre tenga una copy del repository antes de intentar cualquier cosa loca!

Como el repository es local, puede destruir fácilmente el repository haciendo las cosas en los files directamente. De modo que destruir las inputs es, en sí mismo, no es difícil.

Sin embargo, al usar commands, se networkinguce a las extensiones que habilitas en Mercurial. Por ejemplo, la strip es bastante "peligrosa" y está habilitada cada vez que elige usar la extensión mq .

Desde un punto de vista técnico, tanto Git como hg por defecto no cambian los datos que han sido escritos en el pasado. hg siempre solo agrega datos a los files, y Git tiene su representación interna de datos que se conserva en los files que no cambian después de escribirse.