Git Rebase, похоже, сработала, но все фиксации все еще отображаются в журнале... в каком состоянии я вхожу?

Я думаю, что я раздавил последние 40 коммитов, используя rebase. Я следил за этим руководством, чтобы убедиться, что я не сделал ничего глупого - http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

Проблема в том, что я думаю, что я сделал что-то глупое.

Не удалось сохранить (интерактивный) текстовый файл, поэтому кажется, что ошибка была неудачной, но сообщение, которое оно дало, и некоторые другие вещи ниже, предположили, что это могло сработать.

Не знаю, где я и что делать (или даже мое имя). Вот что я сделал:

  • Я набрал git rebase -i HEAD ~ 40
  • Появился текстовый файл, который я редактировал, изменив все строки, чтобы начать с 'squash', кроме верхней
  • Я нахожусь в окнах, используя EditPad... файл не может быть сохранен! Oh noes... (только для чтения/разрешения?).
  • Я сохраняю его в случайном каталоге.

  • Командная строка показывает некоторый успех (к сожалению, я потерял сообщение). Я не знаю, как это может произойти, или узнать, где сохраненный файл...

  • git rebase -continue говорит: "Нет перестановки в процессе?

  • git reflog предлагает, чтобы он работал (по крайней мере, я знаю, слово "rebase" отображается в последних 40 нечетных коммитах), например:

    9992445 HEAD @{8}: rebase: отчеты работают

  • но работает git log показывает все 40 коммитов, которые я просто "перепутал"

Это не выглядит хорошо. Кто-нибудь знает, в каком состоянии я? Я в подвешенном состоянии, было ли это перекосом зомби?

Ответы

Ответ 1

Если переупорядочить список "todo list" не удалось, ваш rebase не работает.

Самый простой способ сквоить, что многие коммиты должны были сделать git reset --soft HEAD~40, а затем git commit с вашим новым сообщением - при условии, что вы хотите сквоить все из них.

Ответ 2

Этот вопрос касается немного удивительного аспекта поведения git rebase -i. Если вы закрываете окно редактора без внесения каких-либо изменений, тогда все еще имеет место rebase. 1 (Это сильно отличается от действия при появлении редактора для фиксации сообщений, когда выходите из своего редактора, не делая любые изменения прерывают фиксацию.)

В вашем случае, поскольку вы сохранили список интерактивных переадресаций в другом месте, а затем вышли из редактора, git предположил, что вы просто хотите повторно использовать все эти коммиты, как и раньше, - он не может сказать, что вы сохранили файл в другом месте, Если история была линейной между HEAD и HEAD~40, тогда история будет точно такой же (включая имена объектов для каждой фиксации), но если бы она была нелинейной, вы переписали бы свою историю так, чтобы она была линейной (и поэтому для некоторых коммитов будут иметь разные имена объектов.)

Возможно, вы захотите проверить в reflog, что HEAD имеет одно и то же имя объекта (хеш) до и после проверки, чтобы проверить это.

1 Хотя в версии, которую я использую, если git может сказать, что результат будет точно таким же, он не утруждает себя фактическим повторным применением коммитов и просто помещает одну запись в рефлоге. Однако эта оптимизация явно не состоялась в вашей ситуации, так как вы можете увидеть повторное применение каждой фиксации в рефлоге.