¿Por qué Git no almacena el nombre de la rama como parte de la confirmación?

Question

Tenga en cuenta: No estoy tratando de reiniciar el argumento de si Mercurial o Git es mejor, solo tengo una pregunta técnica que yo, como usuario de Mercurial, no entiendo. Tampoco estoy seguro de si SO es el lugar adecuado para hacer esa pregunta, pero está relacionado con la programación.

Ha habido muchas discusiones acerca de cómo los dos sistemas de control de versiones Git y Mercurial difieren entre sí desde el punto de vista del usuario (por ejemplo, y http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/), y la principal diferencia es el manejo de ramas. He leído muchas de estas discusiones, pero me sigo haciendo esta pregunta:

¿Por qué Git no almacena el nombre de la rama como parte de la confirmación?

Realmente no veo una buena razón para no hacer eso; significa que los datos simplemente no pueden desaparecer simplemente porque no hay referencia (etiqueta, rama, lo que sea) que se le atribuye.

Veo el almacenamiento de la rama en el compromiso como una gran ventaja para Mercurial, porque eso hace que sea más difícil perder datos.

El punto principal del grupo de Git a favor del modelo de ramificación de Git, que puede simplemente eliminar ramas, no impide que Git almacene el nombre de la rama como parte de cada confirmación: si se borran las confirmaciones de una rama , así son las referencias a esa rama. Tampoco interferirá con el argumento de la "ramificación barata": las sucursales no serán más caras de administrar. Y no creo que el almacenamiento adicional necesario sea motivo de preocupación: solo se trata de un par de bytes por commit.

Answer 1

Uno de la fuente definitiva sobre las ramas de Git y Mercurial es la cuestión de forma:

"Git and Mercurial - Compare and Contrast"

En las referencias Git (ramas, ramas de seguimiento remoto y etiquetas) residen fuera DAG comete

(que permite gestionar diferentes espacios de nombres con respecto a las ramas, por las sucursales locales y remotas)

Usted tiene una idea similar con Mercurial con ramas de marcadores (que puede ser empujado/jalado).

Tenga en cuenta que en Git, los datos no se "desvanecerán" porque no hay referencia: todavía tiene el reflog para recuperar esos commits sin referencia.

¿Por qué Git no almacena el nombre de la rama como parte de la confirmación?
Yo no veo una buena razón para no hacer que

La idea es separar lo ha cambiado (las confirmaciones) de qué m es decir, desde el contexto del cambio (el nombre de la rama).
Como puede fast-forward merge una sucursal, las confirmaciones de una sucursal pueden ser parte de otra en cualquier momento.

Esa es la razón por Jakub Narębski cuestionaron el diseño de Mercurial "ramas" (nombre con nombres de rama incrustados en los metadatos de cambios), sobre todo con un espacio de nombres global, no es muy adecuado para un sistema de control de versiones distribuido .

Crea una rama para aislar un esfuerzo de desarrollo (consulte "When should you branch?"), pero con un DVCS, ese esfuerzo de desarrollo (el conjunto de confirmaciones) debe publicarse bajo cualquier nombre de sucursal. Qué contexto local (nombre de la rama) que ha definido podría no ser válido una vez que se haya publicado en otro repositorio de Git.

Answer 2

El modelo básico de operación de Mercurial son las ramas anónimas, muy simples, que forman un gráfico acíclico dirigido (DAG), y como tales, las ramas tienen poca importancia y usted tendrá que lidiar con ellas mucho menos. Las sucursales con nombre están allí principalmente con fines de organización (ramas de publicación, etc.), por lo que yo diría que un espacio de nombres global tiene más sentido o al menos es menos objetable.

Git tiene un modelo de bifurcación más complicado y administrado que Mercurial, donde incluso sus cambios locales se tratan como una sucursal con nombre diferente, y frente a una plétora de sucursales nombradas debe introducir espacios de nombres para administrarlas. Por la misma razón, Git tiene el concepto de fusiones de avance rápido, algo que no se aplica a Mercurial porque, en primer lugar, no habría creado una rama separada.

Ambos conceptos añaden complejidad adicional y, al mismo tiempo, bloquean funciones útiles, como almacenar el nombre de la rama junto con la confirmación. Esto se debe a que no puede almacenar ramas espaciadas por nombres sin espacio global, y git no tiene ninguna.

La falla en el argumento para los espacios de nombres a los que VonC hizo referencia anteriormente es que asume que hay un problema si tú y yo creamos una rama llamada 'x'. No existe, al igual que no hay ningún problema al crear una rama con nombre, fusionarla y más tarde crear otra con el mismo nombre. Un nombre bien elegido describe lo que hace la sucursal sin importar quién es el autor, y si necesita diferenciar más, el autor se almacena junto con el nombre de la sucursal, y todo esto es permanente.

Creo que fue una muy buena decisión del proyecto Mercurial almacenar el nombre de la rama junto con la confirmación. Al igual que el mensaje de confirmación y el autor, el contexto del trabajo (la rama) es una metainformación importante y útil. Hace mucho más fácil ver el flujo de los conjuntos de cambios cuando se inspecciona el historial, porque se puede ver el contexto en el que se crearon. En Git, he experimentado que sin esta información, la historia se convierte rápidamente en un lío de líneas complicadas que es difícil de crear. cabezas o colas de. Creo que vale la pena el intercambio de no tener espacio de nombres.

Creo que podría decirse que la diferencia filosófica es que Mercurial trata ramas con nombre como metadatos permanentes que brindan información adicional sobre una línea de compromisos, mientras que para Git son un sistema de administración sin versión para desarrolladores en la parte superior de el DAG. Mercurial también los tiene bajo el nombre 'marcadores' por cierto (a partir de la versión 1.8 una característica principal), pero en realidad son más una herramienta de seguimiento y se tratan como etiquetas en lugar de sucursales.