Git Rebase parece haber funcionado, pero todas las confirmaciones siguen apareciendo en el registro ... ¿en qué estado estoy?

Question

Creo que aplasté los últimos 40 commits usando rebase. Estaba siguiendo esta guía para asegurarme de no hacer nada estúpido: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

El problema es que creo que hice algo estúpido.

El archivo de texto (interactiva) no se pudo guardar, por lo que parece que el rebase fracasó, pero el mensaje que dio y algunas otras cosas a continuación sugieren que podría haber funcionado.

No está seguro de dónde estoy ni qué hacer (o incluso cuál es mi nombre). Aquí es lo que hice:

• Mecanografié git rebase -i HEAD ~ 40
• Un archivo de texto se acercó, lo que he editado, cambiando todas las líneas para empezar 'calabaza', excepto el de arriba
• Estoy en Windows, usando EditPad ... ¡el archivo no se puede guardar! Oh noes ... (solo lectura/permisos?).
• Lo guardo en un directorio aleatorio.

• La línea de comandos muestra algún tipo de éxito (lamentablemente he perdido el mensaje). No sé cómo podría tener éxito o sé dónde está el archivo que he ahorrado es ...

• git rebase --continue dice "no rebase en curso?

• git reflog sugiere que funcionaba (de lo conozco al menos, la palabra 'rebase' está mostrando en los últimos 40 confirmaciones impares), por ejemplo:

  9992445 CABEZA @ {8}: rebase: informes de trabajo

• pero el funcionamiento git log muestra los 40 confirmaciones acabo ' rebased '

Esto no se ve bien. ¿Alguien sabe en qué estado estoy? ¿Estoy en el limbo, era esto una rebase de zombies?

Answer 1

Si la rebase "lista de tareas pendientes" no se pudo guardar, su rebase no funcionó.

La forma más fácil de aplastar tantas confirmaciones sería hacer git reset --soft HEAD~40 y luego git commit con su nuevo mensaje, suponiendo que desea aplastarlos a todos.

Answer 2

Esta pregunta es sobre un aspecto ligeramente sorprendente del comportamiento de git rebase -i. Si cierra la ventana del editor sin hacer ningún cambio, entonces la rebase todavía se lleva a cabo. (Esto es muy diferente de la acción cuando el editor de mensajes de confirmación está elevado, donde salir de su editor sin hacer ningún cambio aborta la confirmación.)

En su caso, ya que ha guardado la lista de rebase interactivo en otros lugares , y luego salió del editor, git asumió que solo desea volver a aplicar todos los commits como antes, no tiene manera de saber que ha guardado el archivo en otro lugar. Si el historial fue lineal entre HEAD y HEAD~40, el historial será exactamente el mismo (incluidos los nombres de objeto de cada confirmación), pero si no fuera lineal, habrá reescrito su historial para que sea lineal (y por lo tanto tendrá diferente nombres de objetos para algunas de las confirmaciones).

Es posible que desee comprobar en el reflog que HEAD tiene el mismo nombre de objeto (hash) antes y después de la rebase para comprobar esto.

Aunque en la versión que estoy usando, si git puede decir que el resultado sería exactamente el mismo que no se molesta en realidad volver a aplicar las confirmaciones y sólo pone una sola entrada en el reflog. Sin embargo, esa optimización claramente no se ha producido en su situación, ya que puede ver la reaplicación de cada confirmación en el reflog.