Перечисление и удаление коммитов Git, которые не находятся ни в одной ветке (висячие?)

У меня есть Git-репозиторий с множеством коммитов, которые не относятся ни к одной конкретной ветке, я могу git showих использовать, но когда я пытаюсь перечислить ветки, которые их содержат, он ничего не сообщает.

Я подумал, что это проблема с коммитом / деревом (в результате ветки -D), поэтому я сократил репозиторий, но после этого все еще вижу то же поведение:

$ git fetch origin

$ git fsck --unreachable
$ git fsck

Нет выхода, ничего не болтается (верно?). Но коммит существует

$ git show 793db7f272ba4bbdd1e32f14410a52a412667042
commit 793db7f272ba4bbdd1e32f14410a52a412667042
Author: ...

и он не доступен через любую ветку

$ git branch --contains 793db7f272ba4bbdd1e32f14410a52a412667042

не дает вывода.

Каково состояние этого коммита? Как я могу перечислить все коммиты в похожем состоянии? Как я могу удалить такие коммиты?

Нет выхода, ничего не болтается (верно?)

Обратите внимание, что коммиты, на которые ссылается ваш рефлог, считаются достижимыми.

Каково состояние этого коммита? Как я могу перечислить все коммиты с похожим состоянием

Пройдите, --no-reflogsчтобы убедить git fsckпоказать их вам.

Как я могу удалить такие коммиты?

После истечения срока действия записей reflog эти объекты также будут очищены git gc.

Истечение регулируется gc.pruneexpire, gc.reflogexpireи gc.reflogexpireunreachableнастройки. Срgit help config,

Все значения по умолчанию вполне разумны.

Чтобы удалить все висячие коммиты и те, которые доступны из reflogs, сделайте это:

git reflog expire --expire-unreachable=now --all
git gc --prune=now

Но будьте уверены, что это то, что вы хотите. Я рекомендую вам прочитать страницы руководства, но вот суть:

git gcудаляет недоступные объекты (коммиты, деревья, капли (файлы)). Объект недоступен, если он не является частью истории какой-либо ветви. На самом деле это немного сложнее:

git gc делает некоторые другие вещи, но они здесь не актуальны и не опасны.

Недоступные объекты, которые моложе двух недель, не удаляются, поэтому мы используем, --prune=nowчто означает «удалить недоступные объекты, созданные ранее».

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

Поэтому мы также должны удалить reflogs, чтобы фактически удалить все, что недоступно из ветки. Мы делаем это путем истечения срока действия --allreflogs. Опять же, git хранит немного reflogs, чтобы защитить пользователей, поэтому мы снова должны сказать ему не делать этого:--expire-unreachable=now .

Поскольку я в основном использую reflog для восстановления после деструктивных операций, я обычно использую --expire=nowвместо этого, что полностью сбрасывает reflogs.

У меня была та же проблема, но после того, как я следовал всем советам в этой теме:

git reflog expire --expire-unreachable=now --all
git gc --prune=now
git fsck --unreachable --no-reflogs   # no output
git branch -a --contains <commit>     # no output
git show <commit>                     # still shows up

Если это не рефлог и не ветка, ... это должен быть тег !

git tag                             # showed several old tags created before the cleanup

Я удалил теги с помощью git tag -d <tagname>и повторил очистку, и старые коммиты исчезли.

git branch --contains 793db7f272ba4bbdd1e32f14410a52a412667042

наверное просто нужно быть

git branch -a --contains 793db7f272ba4bbdd1e32f14410a52a412667042

также сообщать о филиалах с удаленных

У меня была похожая проблема. Я побежал git branch --contains <commit>, и ничего не получилось, как в вопросе.

Но даже после запуска

git reflog expire --expire-unreachable=now --all
git gc --prune=now

мой коммит все еще был доступен с помощью git show <commit>. Это было связано с тем, что один из коммитов в его отдельной / оборванной «ветке» был помечен. Я удалил тег, снова выполнил вышеупомянутые команды, и я был золотой. git show <commit>вернулся fatal: bad object <commit>- именно то, что мне было нужно. Надеюсь, это поможет кому-то, кто застрял так же, как и я.

Я случайно попал в ту же ситуацию и обнаружил, что мои тайники содержат ссылку на недостижимый коммит, и, следовательно, предполагаемый недостижимый коммит был доступен из тайников.

Это было то, что я сделал, чтобы сделать его действительно недоступным.

git stash clear
git reflog expire --expire-unreachable=now --all
git fsck --unreachable
git gc --prune=now

git gc --prune=<date>по умолчанию удаляет объекты старше двух недель назад. Вы можете установить более позднюю дату. Но команды git, которые создают свободные объекты, обычно запускают git gc --auto (который удаляет свободные объекты, если их число превышает значение переменной конфигурации gc.auto).

Вы уверены, что хотите удалить эти коммиты? Установка по умолчанию в gc.auto гарантирует, что незакрепленные объекты не займут неоправданное количество памяти, и, как правило, хорошая идея - хранить незакрепленные объекты в течение некоторого времени. Таким образом, если завтра вы поймете, что ваша удаленная ветка содержит необходимый вам коммит, вы можете восстановить его.