git merge recursive theirs, ¿cómo funciona?

Estoy teniendo un problema. Tenemos nuestro propio CMS que está usando git para colaboración y control de versiones y demás.git merge recursive theirs, ¿cómo funciona?

Ahora tengo dos repositorios de git A y B, A, que es un proyecto y B, que es el propio CMS. Ahora quiero conseguir B en A, pero cuando lo hago me sale un montón de Merge-conflictos y la solución de los conflictos es siempre la de utilizar el material de B.

ahora lo que pienso que necesito es

git merge <branch> -s recursive theirs <commit>

porque quiero unirme y cuando hay un conflicto de fusión, debería forzarme a usar la solución de B. Pero no puedo hacer que funcione. Siempre me sigue diciendo fatal: 'theirs' does not point to a commit.

El recursive theirs Encontré here.

¿Alguien sabe lo que hago mal?

Fuente

2010-02-15 Daan Poron

duplicado posible de [¿Cómo selecciono un (?) fusionar la estrategia para una base de datos de git?] (http://stackoverflow.com/questions/2945344/how-do-i-select-a-merge-strategy-for-a-git-rebase) – Louis

Debe utilizar este formulario para pasar opciones de estrategia de combinación:

git merge -s recursive -Xtheirs

También asegúrese de que la versión suppors -Xtheirs, eso es una característica muy reciente

Fuente

2010-02-16 01:47:21 u0b34a0f6ae

fue de hecho el idiota equivocado versión, ahora con la nueva funciona ... solo que no funciona tan bien como pensaba, obtengo todos los conflictos de combinación pero ninguno de ellos contiene ningún conflicto: s –

Esta respuesta parece perder la inclusión de la rama en la fusión? 'git merge -s recursive -Xtheirs ' – robstarbuck

Creo que la razón por la que está fallando es que está especificando "recursivo de ellos" como estrategia. "recursivo" es una estrategia, y cuando pones un espacio después de ella, "suyo" se interpreta como algo con lo que Git necesita fusionar tu copia de trabajo (por ejemplo, otra rama o refspec).

Creo que no podrás especificar una estrategia exactamente como la que quieres. Existe una estrategia llamada "nuestra" que es lo opuesto a lo que usted desea.

El patrón habitual utilizado en esta situación es fusionar o volver a establecer una base de datos en el repositorio "B". Desde la copia de trabajo del repositorio "A", haría una rebase, si es posible (puede que no sea posible, si ya está compartiendo el repositorio de git con otros desarrolladores). Una rebase básicamente revertiría el repositorio A a una confirmación común dentro de ambos repositorios, aplicará confirmaciones "B" y luego confirmará "A" en la parte superior. Resolverías cualquier conflicto de fusión en el camino.

Una vez que pase por el dolor de la fusión o el cambio al repositorio "B", las fusiones futuras serán menos dolorosas.

Fuente

2010-02-15 19:39:57

git merge recursive theirs, ¿cómo funciona?

Respuesta

Cuestiones relacionadas