Ошибка состояния git, в то время как git log и git reflog предоставляют действительные ответы: неверный объект дерева HEAD

git log отлично работает и обеспечивает:

commit ac1d9fec39372683cd20fba15f9c5318b957cf25 (HEAD -> master)
Author: TryerGit <[email protected]>
Date:   Tue Apr 5 20:17:36 2022

    Writeup per suggestion

commit e6cdf4125529fcb8c0b0e131b12c4ab24012cdfd (origin/master)
Author: TryerGit <[email protected]>
Date:   Mon Apr 4 11:54:53 2022

    B4 trying folder specific .gitignore files

commit 54a753a762a7cdfbdea9a0d50deef3b886712cc3
Author: TryerGit <[email protected]>
Date:   Sat Mar 26 17:32:24 2022

    Functionally OKAYish version

... and so on

git reflog отлично работает и обеспечивает:

ac1d9fe (HEAD -> master) HEAD@{0}: commit: Writeup per suggestion
e6cdf41 (origin/master) HEAD@{1}: commit: B4 trying folder specific .gitignore files
54a753a HEAD@{2}: commit: Functionally OKAYish version
... and so on

Однако git status выдает ошибку:

error: bad tree object HEAD

Как можно исправить эту ошибку?


ЭТА: git fsck говорит:

Checking object directories: 100% (256/256), done.
Checking objects: 100% (2338/2338), done.
error: 6e6758bea668ae2fb6271dec137927981548b581: invalid sha1 pointer in cache-tree
broken link from  commit ac1d9fec39372683cd20fba15f9c5318b957cf25
              to    tree 6e6758bea668ae2fb6271dec137927981548b581
missing tree 6e6758bea668ae2fb6271dec137927981548b581
dangling tree 3771f5b131b8934d28373230375c76658c93c0c8

ETA2: облачный механизм синхронизации создает папки в .git/objects/ в случае конфликта, например, fa (2), если fa в данный момент синхронизируется или что-то в этом роде. Итак, я перешел в папку .git/objects/ и переименовал fa (2) обратно в fa. В случае, если присутствовали папки fa и fa (2), я перешел в каждую из этих папок и удалил папку, содержимое которой было старше. Затем оставшуюся папку я переименовал обратно в fa. После этого для всех папок в .git/objects/, в которых были дублированные записи, запуск git fsck возвращает:

Checking object directories: 100% (256/256), done.
Checking objects: 100% (2338/2338), done.

и никаких ошибок, вроде бы указывающих на то, что все хорошо. git status больше не возвращает никаких ошибок. Это может или не может работать в вашем случае. См. комментарий Торека здесь

Что говорит git fsck?

Stephen C 10.04.2022 05:42

@StephenC Обновлен OP с выводом git fsck.

Tryer 10.04.2022 05:44
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
2
33
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Это результат наличия плохого объекта дерева, а именно 6e6758bea668ae2fb6271dec137927981548b581. Сам объект либо вообще не существует, либо внутренне недействителен; вывод git fsck подразумевает первое.

Непонятно, как вы попали в такую ​​ситуацию, но git log сам по себе никогда не замечает, потому что получает совершитьac1d9fec39372683cd20fba15f9c5318b957cf25, который сам по себе цел. Просто этот коммит относится к отсутствующий объект дерева. Пока программа не попытается найти пропавший объект, никто не заметит, что он пропал. Плохой (из-за отсутствия дерева, но не плохой сам по себе) коммит также относится к предыдущему коммиту e6cdf4125529fcb8c0b0e131b12c4ab24012cdfd, который во всех отношениях хорош, и все предыдущие коммиты в порядке.

Если вы сможете найти или воссоздать отсутствующий объект дерева, репозиторий будет восстановлен для использования. В качестве альтернативы, если вы можете заменить плохой коммит хорошим, который ссылается на существующий или новый объект дерева, репозиторий в целом будет в порядке, хотя сохраненный снимок, который был с коммитом 6e6758bea668ae2fb6271dec137927981548b581, исчез.

моя папка .git на разных машинах автоматически синхронизируется через диск Google, который работает на нескольких машинах. Вышеупомянутая ошибка возникает на одной из 3 машин. На двух других нормально. Позвольте мне принудительно скопировать папку .git с рабочей машины на третью машину, где она не работает. У меня была аналогичная ошибка в прошлом, которая была исправлена ​​этим маневром. Спасибо!

Tryer 10.04.2022 05:54

Никогда не помещайте репозиторий в папку, синхронизируемую с облаком, и вы только что столкнулись с одной из причин этого правила: программное обеспечение для синхронизации с облаком будет переименовать файлов на вас (или Git)!

torek 10.04.2022 06:48

Вы говорите, что весь репозиторий: папка .git, файлы в рабочем дереве и т. д. должны быть вне облачной синхронизации? Или только то, что папка .git должна быть вне облачной синхронизации, в то время как файлы рабочего дерева вполне могут быть синхронизированы с облаком? В последнем случае, поскольку папка .git не синхронизируется, каждый коммит придется переделывать на нескольких машинах. Это ненужное повторение. Если вы предлагаете первый случай, то у меня есть большое количество файлов/папок в .gitignore. Как я могу синхронизировать эти файлы между машинами?

Tryer 10.04.2022 06:58

Рабочее дерево могло быть облачным; .git не должен. Думаю, для большинства настроек вам нужно будет использовать --separate-git-dir (или git worktree add).

torek 10.04.2022 09:00

Другие вопросы по теме