2011-02-08 11 views
9

Siguiendo en el escenario de this pregunta, yo estoy realizando un git rebase -s recursive -X theirs etc... y me sorprende que ser detenido con los siguientes tipos de conflictos:¿Git -X "theirs" no maneja los conflictos de archivos nuevos/eliminados?

  • añadidos por ellos
  • eliminados por ellos
  • suprimen por nosotros

¿Hay alguna razón por la cual la estrategia no resuelve estos problemas?

(no sé si esto es significativo, pero git no informe conflictos en la salida, sólo dice When you have resolved this problem run "git rebase --continue")

ACTUALIZACIÓN Aquí hay un script que no acaba de reproducir, pero casi:

git init 
git symbolic-ref HEAD refs/heads/Branch1 #just to get the 'right' branch name 
echo Added in A > DeletedByThem.txt 
git add -A 
git commit -m A 

echo Modified in B >> DeletedByThem.txt 
git add -A 
git commit -m B 

echo Modified in C >> DeletedByThem.txt 
echo Added in C > DeletedByUs.txt 
git add -A 
git commit -m C 

git checkout -b Branch2 
echo Modified in D >> DeletedByUs.txt 
git rm DeletedByThem.txt 
git add -A 
git commit -m D 

echo Modified in E >> DeletedByUs.txt 
git add -A 
git commit -m E 

En este punto, usted debe tener presente:

Branch1: A - B - C 
        \ 
Branch2:    D - E 

Lo que queremos es la siguiente:

Branch1: A - B - C 
       \ 
Branch2:   D - E 

Así:

git rebase -s recursive -X theirs --onto [SHA of B] Branch1 Branch2 

Esto reproduce el 'borrado por ellos' y 'nosotros' borrado problemas, pero no reproduce el 'agregado por ellos' , ni la ausencia de ningún informe de conflicto.

De lo que puedo deducir, en este contexto 'borrado por ellos' significa "modificado después de B, luego eliminado" (entonces do queremos eliminarlo en Branch2), y "borrado por nosotros" significa " creado después de B "(así que queremos mantenerlo en Branch2)

Por lo que puedo decir de la historia de mi real (y enorme) repos, el 'agregado por ellos' se relaciona con nombres cambiados incorrectamente detectados (es decir, archivos idénticos en carpetas completamente diferentes que se identifican como renombrados).

+0

¿Simplemente está infiriendo que estos son los conflictos, o los informa al intentar aplicar parches, luego los resuelve correctamente y por lo tanto no los informa en el resultado de 'git status'? – Cascabel

+1

Supongo que estoy infiriendo, dado que la rebase se detiene. – Benjol

+1

@Jefromi, lo siento, me olvidé de @ mi último comentario. Actualmente estoy intentando escribir algo para reproducir esto ... – Benjol

Respuesta

2

La razón por la que obtienes un conflicto es porque rebase está intentando aplicar un parche que es imposible de aplicar.

El archivo que el parche nos indica que eliminemos, no puede encontrarlo.

Este comportamiento es por diseño.

+1

Recibo el mismo aviso de conflicto (lo borro) pero existe un archivo, por lo que no estoy seguro de si ese es siempre el caso. – pilau

Cuestiones relacionadas