conflicto de git rebase fusionando files incorrectos

Tengo lo que creo que es un problema realmente extraño con los conflictos de fusión durante una rebase.

Estoy tratando de volver a establecer una base de una twig de características con una twig de desarrollo:

git checkout myFeatureBranch git rebase developBranch 

Ahora git rebase reporta conflictos y tengo que usar git mergetool para resolver conflictos.

 git mergetool 

Git mergetool declara un file conflictivo myFile1.h y se abre la interfaz de combinación (el problema ocurre en Linux o Windows / tortoisegit para el mismo repository). Lo que veo es que el file "suyo" es completamente el file incorrecto myOtherFile.c aunque el file "mío" muestra correctamente myFile1.h .

He intentado git gc --aggressive y git fsck --full . git gc informa que no hay ningún problema y git fsck tiene muchas cosas colgantes, pero no hay errores o falta información.

¿Es esto algún tipo de corrupción en la database de git y, de ser así, puede repararse?

¿Alguna otra posibilidad para lo que está mal?

Pensé que tal vez podría fusionar el file "mío" de nuevo (ignorando por completo todos los cambios "suyos" incorrectos), y tal vez esto resolvería el problema, pero me temo que también podría empeorar las cosas.

Cualquiera que sea el problema, parece estar en nuestro repository remoto maestro ya que los nuevos clones exhiben el mismo problema de rebase.

Gracias por tu ayuda.

git config -l salida con alguna networkingacción:

 core.symlinks=false core.autocrlf=input color.diff=auto color.status=auto color.branch=auto color.interactive=true pack.packsizelimit=2g help.format=html http.sslcainfo=/bin/curl-ca-bundle.crt sendemail.smtpserver=/bin/msmtp.exe diff.astextplain.textconv=astextplain rebase.autosquash=true core.autocrlf=true core.excludesfile=<global exclude file> user.name=Russell user.email=<email address> push.default=simple core.repositoryformatversion=0 core.filemode=false core.bare=false core.logallrefupdates=true core.symlinks=false core.ignorecase=true core.hidedotfiles=dotGitOnly remote.origin.url=<gituser@gitserver> remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.puttykeyfile=<key.ppk> branch.master.remote=origin branch.master.merge=refs/heads/master branch.develop.remote=origin branch.develop.merge=refs/heads/develop branch.myFeatureBranch.remote=origin branch.myFeatureBranch.merge=refs/heads/myFeatureBranch 

Estás corriendo en la detección de cambio de nombre de git.

Primero, algunas notas importantes sobre rebase.

  1. Rebase usa la maquinaria de fusión.

  2. En una fusión (p. Ej., Fusión de la feature con el master ) diría "la twig en la que estoy, master , es 'nuestro' código y la twig en la que estoy fusionando, feature , es 'su' código".

Cuando rebase el código, el lado "nuestro" es el código que está modificando, y el código "suyo" es el código que está modificando, es decir, su propio código. En efecto, los "lados" se intercambian. (Ver los arguments -m , -s y -X para git rebase y la nota sobre los lados intercambiados.)

Dentro de la maquinaria de fusión, usando la estrategia pnetworkingeterminada ( recursive ), git piensa que "nuestro" myFile1.h (es decir, el de develop ) es más similar a "their" myOtherFile.c (es decir, su propia versión de ese file) que a "su" (es decir, su) myFile1.h . Así que está intentando fusionar los files incorrectos.

Diríjase a la documentation de git merge , tenga en count las opciones que puede pasar a recursive . El más importante es probablemente rename-threshold=<n> . Por lo tanto, puede pasar -X rename-threshold=100 (o cualquier número suficientemente superior a 50). Nunca me he encontrado con este problema, pero parece que debería funcionar.

git rebase -p develop pareció hacer el truco. Gracias a jthill .

Todavía no he intentado get la respuesta, pero planeo explorar eso también, por curiosidad.

¿Por qué las fusiones en la historia hacen alguna diferencia?

Rebase es una herramienta de networkingucción de ruido para evitar networkingundancias de eliminación de time de pu {bli,} shed history. Una vez que haya hecho lo que merece ser escrito, rebase es la rebase "escriba lo que merece ser leído". Por un golpe por golpe, simplemente se fusionaría, cuando eso complicaría innecesariamente los trabajos de los lectores, uno por uno linear sería casi siempre lo suficientemente bueno y fácil, así que eso es lo que la networkingistribución intenta de forma pnetworkingeterminada. Si no resulta tan fácil, hay -i y -p , --interactive y --preserve-merges , para ayudar con la edición más compleja.