Вопросы Теги

Удалите файл из репозитория мерзавца (история)

(решенный, посмотрите нижнюю часть тела вопроса),
Поиск этого в течение долгого времени теперь, что я имею до настоящего времени:

В значительной степени тот же метод, но они оба оставляют объекты в файлах пакета... Застрявший.
Что я попробовал:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_name'
rm -Rf .git/refs/original
rm -Rf .git/logs/
git gc

Все еще имейте файлы в пакете, и это - то, как я знаю это: 

git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3

И это:

git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch file_name" HEAD
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

То же...

Испытанный git clone прием, это удалило некоторые файлы (~3000 из них), но самые большие файлы все еще там...

У меня есть некоторые большие файлы прежней версии в репозитории, ~200M, и я действительно не хочу их там... И я не хочу сбрасывать репозиторий к 0 :(

РЕШЕНИЕ: Это - самый короткий способ избавиться от файлов:

  1. проверьте .git/packed-refs - моя проблема состояла в том, что я имел там a refs/remotes/origin/master строка для удаленного репозитория, удалите его, иначе мерзавец не удалит те файлы
  2. (Дополнительно) git verify-pack -v .git/objects/pack/#{pack-name}.idx | sort -k 3 -n | tail -5 - проверять на самые большие файлы
  3. (Дополнительно) git rev-list --objects --all | grep a0d770a97ff0fac0be1d777b32cc67fe69eb9a98 - проверять, что является теми файлами
  4. git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_names' - удалить файл из всех изменений
  5. rm -rf .git/refs/original/ - удалить резервное копирование мерзавца
  6. git reflog expire --all --expire='0 days' - истечь все свободные объекты
  7. git fsck --full --unreachable - проверять, существуют ли какие-либо свободные объекты
  8. git repack -A -d - переупаковка
  9. git prune - наконец удалить те объекты

76
задан Boris Churzin 11 February 2015 в 12:40
поделиться

3 ответа

Я не могу сказать точно без доступа к данным вашего репозитория, но мне кажется, что, вероятно, есть один или несколько упакованных ссылок на старые коммиты, сделанные до того, как вы запустили git-фильтр-отделение . Это объясняет, почему git fsck --full --unreachable не называет большой блок недоступным объектом, даже если вы просрочили свой рефлог и удалили оригинальные (распакованные) ссылки.

Вот что я бы сделал (после того, как git фильтр-отделение и git gc были сделаны):

1) Убедитесь, что оригинальные ссылки отсутствуют:

rm -rf . git/refs/original

2) Истечение всех записей в git-рефлоге:

git-рефлог истекает --all --expire='0 days'

3) Проверка старых упакованых ссылок

Это потенциально может быть сложно, в зависимости от того, сколько у вас упакованых ссылок. Я не знаю ни одной команды Git'а, которая бы это автоматизировала, так что, думаю, вам придётся сделать это вручную. Сделайте резервную копию .git/пакованных ссылок . Теперь отредактируйте .git/packed-refs. Проверьте старые ссылки (в частности, посмотрите, не упаковано ли какое-либо из ссылок из .git/refs/original). Если вы нашли какие-то старые ссылки, которые не должны быть там, удалите их (удалите строку для этого ссылки).

После завершения очистки файла packed-refs убедитесь, что git fsck заметил недоступные объекты:

git fsck --full --unreachable

Если это сработало, и git fsck теперь сообщает Вашему большому блоку, что он недоступен, Вы можете перейти к следующему шагу.

4) Переупаковка Вашего упакованного архива(ов)

git переупаковка -A -d

Это гарантирует, что недоступные объекты будут распакованы и останутся распакованы.

5) Обрезать недоступные (недоступные) объекты

git prune

И это должно сработать. У Git'а действительно должен быть лучший способ управления упакованными рефсами. Может быть, есть лучший способ, о котором я не знаю. В отсутствие лучшего способа ручное редактирование файла packed-refs может быть единственным.

64
ответ дан 24 November 2019 в 11:22
поделиться
- 3665334-

См.: Как удалить конфиденциальные файлы из истории Git

. Вышеуказанное не удалось, если файл не существует в Rev. В этом случае переключатель «-GIGNORE-Onlatch» исправит его: 

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch <filename>' HEAD

затем, чтобы получить все свободные объекты из репозидара: 

git gc --prune='0 days ago'
2
ответ дан 24 November 2019 в 11:22
поделиться

У вас есть разные причины для неподвижного большой размер репозитория git после git gc , поскольку он не удаляет все незакрепленные объекты .

Я подробно описываю эти причины в статье « уменьшить размер репозитория git »

Но один трюк, который нужно проверить в вашем случае, - это клонировать ваш «очищенный» репозиторий Git и посмотрите, имеет ли клон подходящего размера.

("очищенное" репо '- это то место, где вы применили filter-branch , а затем gc и обрезать )

{ {1}}
1
ответ дан 24 November 2019 в 11:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: