Depurando por qué git (svn) rebase no detecta el parche (noop)?

Tengo un repository de git-svn ( error de fusión inesperado en un sistema git svn? ); tiene un control remoto llamado origingit refiere a otro git repo, además de git-svn que se refiere a un repository SVN.

 $ git branch -a * master remotes/git-svn $ git remote show origingit $ tree .git/refs/{heads,remotes} .git/refs/heads └── master .git/refs/remotes ├── git-svn └── origingit 

Este es el problema: cuando lo hago

 git pull --rebase origingit master 

git divide el tree, por lo que todos los commits desde origingit que no han sido parte del git svn clone original pierden su git-svn-id (son "locales", ver git-svn-id falta en algunos commits ) ; en este caso, las confirmaciones relevantes se ven así (todas tienen "edición nula" en el nombre):

 $ git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order | grep 'null edit' * cae158d (git-svn) : null edit A06 * 8f79edf : null edit A05 * 0c7373e : null edit A04 * b4bf336 : null edit A03 * e05cfc6 : null edit A02 | * e0c6823 (HEAD, master) : null edit A07 | * 03ed433 : null edit A06 | * de3bd53 : null edit A05 | * 65bf738 : null edit A04 | * 62ab3f6 : null edit A03 * | 964b300 : null edit A01 | * 14f5aba : null edit A02 | * f0ef194 : null edit A01 

Tenga en count que el master ha recogido la última "edición nula A07", que entró desde origingit.

Cuando lo hago

 git svn rebase 

… todos los commits presentes en el repository SVN deberían get un git-svn-id , y aquellos que aún no están asignados a SVN no lo hacen, pero se enumeran después (a time, o primero en order) git-svn-id unos en git log ; así que en el próximo git svn dcommit , esos locales se comprometerían a SVN. Sin embargo, en este caso particular, obtengo el log --graph como:

 * cae158d (HEAD, git-svn, master) : null edit A06 * 8f79edf : null edit A05 * 0c7373e : null edit A04 * b4bf336 : null edit A03 * e05cfc6 : null edit A02 * 964b300 : null edit A01 

De hecho, aquí git svn rebase salida a stdout simplemente "Primero, rebobinar el cabezal para reproducir tu trabajo encima …" y sale; de lo contrario, generalmente dice "Aplicar: …" que aparentemente se refiere a parches (y … es el post de confirmación para esos locales), y en ese caso, el logging esperado sería:

 * xxxxxxx (HEAD, master) : null edit A07 * cae158d (git-svn) : null edit A06 * 8f79edf : null edit A05 * 0c7373e : null edit A04 * b4bf336 : null edit A03 * e05cfc6 : null edit A02 * 964b300 : null edit A01 

Entonces, incluso si la null edit A07 es claramente una confirmación válida en el repository origingit, y viene después de la null edit A06 uno (que también está presente en SVN), git svn rebase no aplica este parche. ¿Por qué? ¿Y cómo es posible?

En cualquier caso, desde este punto, puedo hacer git pull --rebase ... y llegar al estado anterior que se muestra.

Aquí sería muy bueno si hubiera alguna installation de debugging, que podría decir cómo git rebase pasa por cada confirmación y decide qué hacer, pero desafortunadamente, --verbose acaba de volcar una list de files modificados entre el último git-svn- id commit y el último HEAD, por lo que no ayuda mucho.

Agregando algunas impresiones a /usr/lib/git-core/git-svn , pude ver que git svn rebase finalmente llama a git rebase refs/remotes/git-svn ; así que traté de agregarle interactivo:

 $ git pull --rebase origingit master ... $ git rebase --interactive refs/remotes/git-svn 

… y eso nos muestra:

 noop # Rebase cae158d..e0c6823 onto cae158d # # Commands: [...] 

Por lo tanto, la aplicación de parches no ocurre durante la rebase, porque no encuentra que deba hacerse ningún parche. Pero, ¿cómo es eso posible? Observando que cae158d es el SHA de "null edit A06" dentro de git-svn (y está presente tanto en SVN como en origingit), mientras que e0c6823 es el SHA de "null edit A07" que vino de origingit – donde se encuentra inequívocamente y sin ningún problema como un compromiso (es decir, debe haber un cambio real de la revisión anterior) después de la "edición nula A06" ??

Entonces, ¿cómo puedo inspeccionar por qué sucede esto? Y finalmente, ¿cómo puedo obligar a git svn rebase a reconocer durante git svn rebase que hay un parche allí?