Git поврежден? `reword` `git rebase -i` внезапно перестал работать
ТЛ;ДР
Я пользовался reword инструкцией git rebase -i без проблем в течение нескольких лет.
Однако он больше не работает только в одном из моих локальных репозиториев Git.
Как ни странно, проблема решается просто разветвлением репозитория локально.
Как размножать
Подтверждает, что перебазирование не выполняется и рабочий каталог чист.
$ git status On branch x nothing to commit, working tree clean $ git rebase --abort fatal: no rebase in progressЗапускает интерактивную перезагрузку.
$ git rebase -i developРедактирует список изменений.
pick 0a280af1 commit_1 pick 4c37991e commit_2 - pick 09191dca commit_3 + reword 09191dca commit_3 pick cb098966 commit_4 pick 670ce5d9 commit_5Редактирует сообщение фиксации при появлении соответствующего запроса.
rewordсам по себе успешен, ноpickсразу после этого терпит неудачу по неизвестной причине.commit_4_{a|b}.txtв сообщении об ошибке уже отслеживаются иcommit_4редактирует их.Остальные коммиты (т. е.
commit_{1|2|3|5}) их не трогают.Как было подтверждено на шаге 1 выше, на момент запуска рабочий каталог был чистым (без локальных изменений)
git rebase -i.
[detached HEAD 79925137] new_commit_3 Date: Mon Sep 2 15:55:29 2024 +0900 2 files changed, 185 insertions(+) create mode 100644 commit_3_a.txt create mode 100644 commit_3_b.txt error: Your local changes to the following files would be overwritten by merge: commit_4_a.txt commit_4_b.txt Please commit your changes or stash them before you merge. Aborting hint: Could not execute the todo command hint: hint: pick cb0989660941c763e6935d63105205e296a2c11f commit_4 hint: hint: It has been rescheduled; To edit the command before continuing, please hint: edit the todo list first: hint: hint: git rebase --edit-todo hint: git rebase --continue
Обходной путь
У меня есть странный обходной путь.
Локально разветвляет репозиторий.
$ cd /path/to/new_directory $ git clone /path/to/original_projectВыполняет те же действия, что и в разделе «Как воспроизвести» выше.
Это работает как шарм.
Среда
macOS Sonoma (M3 Apple Silicon)
Git 2.46.0 (устанавливается через Homebrew)
Вопрос
Как я могу устранить проблему?
@eftshift0 (Q1) Были ли commit_4_a.txt и commit_4_b.txt проигнорированы/не отслежены? (A1) Они уже отслеживаются и commit_4 их редактируют. Остальные коммиты (т. е. commit_1, ..., commit_5, кроме commit_4) их не трогают. (Q2) Похоже, у вас есть изменения в тех файлах, которые не зафиксированы локально (A2) Как показано в ОП, я проверил, что рабочий каталог полностью чист с помощью git status. Разве этого недостаточно? В какой момент (или фазу, или шаг) мне следует выполнить git show --name-status --pretty = ""?
Итак, если запустить git status, то он сейчас чистый, если я правильно понимаю. Вы случайно не использовали git update-index --assume-unchanged с этими двумя файлами?
@eftshift0 (Q1) Итак, если вы запустите git status, он прямо сейчас чист (A1) Да. Здесь чисто. (Q2) Использовали ли вы git update-index --assume-unchanged (A2) Нет. Я даже не знал команду update-index. (Q3) вам не следует выполнять выбор и перефразирование как две отдельные операции... (A3) Извините. То, как я написал этот шаг, было неоднозначным. Я показал изменение в так называемом стиле различий. На самом деле я заменил pick на reword.
и я получил это после того, как внимательно посмотрел на то, что вы сделали, поэтому я удалил комментарий об этом.
Хорошо, это status, которое у вас есть... это статус до начала перебазирования? Потому что я хотел бы посмотреть, каков статус, когда происходит сбой перебазирования в том коммите, который вы переформулируете.
@eftshift0 Рабочие каталоги перед началом перебазирования и сразу после сбоя оба чисты. (Первый показан в ОП. Последний не показан в ОП, но я только что проверил это сейчас.)
Возможно, запуск git с GIT_TRACE=1 может дать нам некоторую информацию?
Похоже, у вас проблемы с файловой системой, нечувствительной к регистру, или с именами файлов, отличными от ASCII.
@eftshift0 Я сравнил результаты GIT_TRACE=1 git rebase -i develop, выполненные в проблемном репозитории и в исправном локальном форке. Разница заключалась в том, что я инициализировал только подмодуль Git в бывшем репозитории. Итак, я попробовал git submodule deinit, и это решило проблему, хотя серия коммитов совершенно не имеет отношения к подмодулю. Повторное выполнение git submodule init возобновляет проблему. Я тоже пробовал git gc, git fsck, но безрезультатно. Выполнение git submodule init в развилке НЕ выявило проблему. Я сдаюсь... Спасибо за множество советов!
@j6t Имена файлов в формате ASCII. Я использую файловую систему без учета регистра, поскольку работаю в macOS. Однако они не должны иметь значения, поскольку, как показано в ФП, простое клонирование того же репозитория локально решает проблему. Как я только что написал в этом комментарии, я сдаюсь... Отладка этой странной проблемы отнимает слишком много времени. Я воспользуюсь вилкой; оба имеют одинаковое содержание.
Ответы 1
ТЛ;ДР
Кэш подмодуля Git (т. е. .git/modules) был поврежден. Простое удаление каталога и повторная инициализация подмодуля решили проблему.
Хотя я не знаю почему.
Как написано в этого комментария, я сравнил выходные данные GIT_TRACE=1 git rebase -i develop, выполненные в исходном проблемном проекте, и результаты, выполненные в не проблемной локальной вилке, и обнаружил, что я инициализировал подмодуль Git только в первом случае.
Итак, я попробовал следующие шаги:
Я выполнил
git submodule deinit <directory name>, чтобы деинициализировать подмодуль в бывшем репозитории. После этогоrewordначал работать без проблем.Тем не менее, мне нужен субмодуль. Поэтому я снова выполнил
git submodule init. Из-за этогоrewordснова потерпел неудачу.Затем в непроблемной вилке я выполнил
git submodule init. Тем не менееrewordработал.
Эта отладка подразумевает кеш подмодуля (т. е. .git/modules) в бывшем репозитории был поврежден (хотя git gc и git fsck не работали).
Это не должно иметь значения, поскольку серия перебазируемых коммитов совершенно не имеет отношения к содержимому подмодуля и не зависит от него. Но в любом случае я попробовал:
git submodule deinit <directory name>mv .git/modules/ .git/modules.bak(удаляет кеш подмодуля)git submodule initgit submodule update
Теперь reword снова работает.
Я думаю, что сообщение очень ясно описывает то, что происходит. Были ли
commit_4_a.txtиcommit_4_b.txtпроигнорированы/не отслежены? Похоже, у вас есть изменения в тех файлах, которые не зафиксированы локально, и поэтому git предупреждает вас об этом, чтобы вы не потеряли их, потому что выбираемый там коммит (cb0989660941) содержит для них изменения (отметьтеgit show --name-status --pretty = "" cb0989660941).