Subversion tiene –record-only for merges, ¿cómo hago lo mismo en Git?

Tengo un repository donde 'master' va en una cierta dirección, y una segunda 'foo' va a ser divergente por un par de confirmaciones, luego sigue todos los cambios posteriores a 'master' después de eso. Esto es todo por elección, por supuesto.

En Subversion, podría hacer una fusión de solo logging para marcar cosas como "se ha producido la fusión", aunque no se hayan confirmado cambios reales. es decir, esto cambia los numbers de seguimiento de fusión en las properties adjuntas a los directorys en la twig de destino.

He tenido una jugada con …

git merge –no-commit master

… como algo con lo que pueda jugar antes de hacer el commit, pero está haciendo un desastre en la twig objective por parte del cambio en cuestión (rename seguido por delete).

Debe haber una manera más fácil …

  • Pablo

Es esto lo que estás buscando?

git merge --strategy=ours master 

la nuestra

Esto resuelve cualquier cantidad de encabezados, pero el tree resultante de la fusión es siempre el del encabezado de bifurcación actual, ignorando todos los cambios de todas las otras twigs. Está destinado a ser utilizado para replace el historial de desarrollo anterior de las twigs laterales.

Esto parece ser lo que estás pidiendo: crea un compromiso de fusión que en realidad no introduce ningún cambio.

¿Pero realmente quieres hacer esto? ¿Hay alguna razón por la que no puedas simplemente dividir las twigs (sin que se produzca una fusión) y luego fusionarte más tarde?

Paul, git maneja el cambio de nombre seguido por eliminar con (relativo a svn) facilidad. Se rastrea el contenido, no el nombre de file. En svn esto sería doloroso, ¿qué problemas estás experimentando con git mientras haces esto?

jefromi lo clavó. Aquí está la cosa real: http://github.com/jbehave/jbehave-core/blob/master/examples/trader/src/main/java/org/jbehave/examples/trader/TraderStory.java (jugar con las twigs de cambio y mira la línea 65).

No se trataba tanto de "tirar la historia", sino más de usar Git para hacer malabares con los cambios divergentes desde una única base. Para hacer que la gente adopte JBehave (IMO) necesitamos hacer ejemplos realmente fáciles de seguir. Antes de este ejemplo 'Trader', JBehave vainilla + una variante de Guice + una variante SpringFramework + una variante de PicoContainer, todo en el mismo directory de origen. Ahora, cuatro twigs pueden ilustrar la mayoría de las representaciones canónicas del ejemplo de 'Comerciante'.