¿Pensamos en los commits de Git como diffs, snapshots y/o historiales?

Artículo original ↗ Discusión en Hacker News ↗

Si los commits de Git deben entenderse como diffs, snapshots o historiales completos resulta ser algo que moldea cómo la gente aprende, enseña y usa Git de forma segura. Los comentaristas contrastan el modelo real de almacenamiento de Git (snapshots direccionados por contenido en un DAG, con compresión delta como detalle de implementación) con el comportamiento de los comandos principales, señalando que muchas operaciones (rebase, cherry-pick, merge) tratan conceptualmente los commits como cambios entre snapshots. Un tema recurrente es que los modelos mentales simplistas o engañosos —especialmente “los commits son diffs”— pueden dificultar el razonamiento sobre flujos de trabajo avanzados y resolución de conflictos, por lo que elegir y explicar las abstracciones con cuidado se ve como algo crucial para la productividad de los desarrolladores.

Modelos mentales: diffs, snapshots, historiales

  • Muchos sostienen que los commits son conceptualmente snapshots: un estado completo del repositorio (árbol) más punteros a los padres, formando un DAG.
  • Otros piensan instintivamente en los commits como diffs/cambios, porque uno escribe “un cambio” y herramientas como git show, rebase, cherry-pick y las revisiones presentan u operan sobre diffs.
  • “Historial” se describe como un commit más todos sus ancestros (lo que otros sistemas llaman una rama); algunos encuentran confusa la distinción “historial vs snapshot” ya que cada snapshot enlaza a ese historial.
  • Varios proponen una visión dual (o triple): los commits como snapshots, diffs y partes del historial, con el modelo “correcto” dependiendo de la operación.

Implementación vs abstracción

  • Hay un fuerte desacuerdo sobre si “cómo lo implementa git” es un buen modelo de enseñanza.
  • Un lado: los commits como snapshots y el almacén de objetos (trees, blobs, direccionamiento por contenido) son esenciales para que los desarrolladores eviten confusiones en merges/rebases.
  • El otro lado: la implementación (incluyendo packfiles y compresión delta) es una optimización y a menudo distrae a los principiantes; la interfaz trata sobre estados a lo largo del tiempo, con diffs derivados bajo demanda.
  • Un debate más amplio usa una analogía del pedal del acelerador: algunos enfatizan abstracciones intuitivas, otros sostienen que las abstracciones con fugas y las necesidades de depuración hacen valioso conocer la implementación real.

Rebases, merges y el DAG

  • El rebase se describe como “resetear a una nueva base + cherry-pick de cada commit”, aplicando conceptualmente diffs por commit mediante merges de 3 vías.
  • Varios señalan que pensar puramente en diffs durante los rebases causa confusión, especialmente cuando cambia el orden de los commits o cuando intervienen commits de merge.
  • Los commits de merge pueden introducir cambios nuevos arbitrarios (incluida la resolución de conflictos) y pueden romper padres que funcionaban; “historial de merge = historial seguro” se marca como inseguro.

Almacenamiento y rendimiento

  • Se aclara que el modelo lógico de git son snapshots; el almacenamiento físico puede usar compresión delta (“deltas”) dentro de packfiles, pero eso es invisible para los usuarios.
  • Las explicaciones detallan árboles copy-on-write, deduplicación pesada mediante hashes y por qué esto sigue siendo rápido y eficiente en espacio incluso con muchos commits.
  • Algunos argumentan que llamar “diffs” a los commits por culpa de los deltas de packfile es engañoso; otros creen que es aceptable si “diff” se define de forma laxa.

Enseñanza, usabilidad y otras herramientas

  • Varios dicen que el “modelo mental de diff” es la principal fuente de confusión cotidiana y abogan por enseñar siempre snapshots primero.
  • Otros reportan éxito a largo plazo pensando en diffs, afirmando que rara vez necesitan el modelo de snapshot explícitamente.
  • La interfaz y la terminología de git son ampliamente criticadas por confusas y demasiado ligadas a los internals; Mercurial se cita con frecuencia como un modelo más limpio y más amigable para el usuario (aunque ahora de nicho).

Diffs y su no unicidad

  • Los comentaristas subrayan que no existe un único diff canónico: los algoritmos y opciones (--word-diff, patience, histogram, hunks conscientes del lenguaje) cambian lo que ven los usuarios.
  • Esto puede no coincidir con cómo los autores conceptualizan sus ediciones, pero la mayoría acepta “un diff, no el diff” por uso práctico.