Как удалить оборванные коммиты в удаленном репозитории git, таком как VSTS

Я пытался уменьшить размер своего репозитория Git, переместив некоторые файлы в git LFS. Еще несколько 100 команд, и вот мы с файлами в git LFS и больше нет истории этих файлов в моих коммитах git.

Однако всякий раз, когда я клонирую репозиторий, я все еще загружаю около 3 ГБ объектов. Я обошел эту проблему, создав новый репозиторий в Visual Studio Team Services, и после локальной обрезки и сбора мусора в моем репозитории, а затем отправки туда, он был уменьшен до 300 МБ. (Команда для этого находится локально в этом сообщении: Git: что такое висячий коммит/блоб и откуда они берутся?)

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

Я также пытался выполнить git init, а затем применить его к существующему репозиторию, но это только увеличило количество объектов.

Для тех, кто также сталкивается с подобными проблемами, это была команда, которую я выполнил, чтобы создать новый репозиторий без оборванных коммитов, однако я хотел бы узнать, как это сделать в существующем репозитории, не удаляя его:

git clone https://avavedse.visualstudio.com/Test/_git/TestRepository
cd blahblah
git reflog expire --expire=now --all
git gc --prune=now
git remote add newrepo https://avavedse.visualstudio.com/Test/_git/TestRepositoryNewEdition
git push newrepo

git azure-pipelines visual-studio git-lfs git-clone
person Devedse    schedule 24.05.2017    source источник
comment
Перезапись LFS — очень важная модификация репозитория; почему вы не можете представить, что это требует полной замены пульта? Для справки, если служба удаленного хостинга обеспечивает контроль над git gc, вы можете очистить его, а не заменить, но обычно я на это не рассчитываю.   -  person Mark Adelsberger    schedule 24.05.2017
comment
Потому что это подразумевает необходимость фактически вносить функциональные изменения в репозиторий, чтобы обойти техническое ограничение.   -  person Devedse    schedule 24.05.2017
comment
Как же так? У вас есть пульт с набором рефов; вы удаляете его и заменяете новым репо с теми же ссылками (даже указывая на те же коммиты), но с меньшим раздуванием. Что это за функциональные изменения? В отличие от этого, когда вы запустили миграцию LFS, которая изменила все ваши ссылки, чтобы они указывали на новые коммиты, это уже было функциональным изменением, которое потребует от любого пользователя выполнения восстановления (проще всего справиться с отбрасыванием и замена всех клонов). Поскольку миграция LFS является настолько радикальным функциональным изменением, насколько это возможно, я не понимаю беспокойства.   -  person Mark Adelsberger    schedule 24.05.2017
comment
Вы, кажется, защищаете это ограничение продукта, и я, честно говоря, понятия не имею, почему? Почему люди должны удалять и полностью пересоздавать репозиторий только для того, чтобы достичь своей цели по уменьшению размера этого репозитория. Их требования не включают в себя новый репозиторий, это просто обходной путь/хак для функциональности, которая, судя по вашей истории, похоже, не реализована в продукте. Кроме того, я не уверен, какое другое влияние окажет удаление/воссоздание репозитория, будут ли сохранены запросы на вытягивание?, проблемы? и т. д.   -  person Devedse    schedule 24.05.2017
comment
То, что вы думаете, что все должно быть оценочным суждением, — это ваша проблема, а не моя. Я рассказываю вам, как это работает, и прошу вас объяснить, почему это создает для вас практические проблемы. Если проблема в том, что я думаю, что это должно быть по-другому, то это не ПРАКТИЧЕСКАЯ проблема; но, эй, не стесняйтесь обсудить это с поставщиком услуг или сменить поставщика услуг. Если выбранный вами поставщик услуг хостинга git не предоставляет интерфейс gc — а я полагаю, что VSTS — нет, вам необходимо заменить репо. Период.   -  person Mark Adelsberger    schedule 24.05.2017

Ответы (2)


arrow_upward
3
arrow_downward

Это может быть дубликат Как удалить оборванную фиксацию из GitHub. ?

GitHub будет периодически собирать объекты, которые не могут быть доступны из ссылки верхнего уровня. Так что со временем они исчезнут. Но это не гарантируется. Это лучшая информация, которую я нашел по этому поводу.

Вы можете вручную исправить дату истечения срока действия reflogs и запустить сборщик мусора:

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

Но это повлияет только на локальное репо.

Судя по всему, сборщик мусора далек от идеала, настолько, что если вы не возражаете против удаления и создания нового репо и потери всех проблем, пулл-реквестов и т.д., вам нужно обращаться в Поддержка Github :

вы можете безвозвратно удалить кешированные представления и ссылки на конфиденциальные данные в запросах на вытягивание на GitHub, обратившись в службу поддержки GitHub или в службу поддержки GitHub Premium.[docs.github.com]

person Kukuster    schedule 01.08.2020

arrow_upward
1
arrow_downward

На самом деле, когда вы выполняете git reflog expire --expire=now --all и git gc --prune=now, висячие коммиты удаляются. Вы можете перепроверить git fsck --full. Если вывод не показывает коммиты, это означает, что зависших коммитов нет.

Другая причина, по которой размер репо не уменьшился, по-видимому, заключается в том, что вы не удалили файлы LFS в истории git. Вы можете переписать историю:

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch filename --prune-empty --tag-name-filter cat -- --all
git push -f

Более подробную информацию о перемещении файлов из git в git-lfs вы можете найти по адресу перемещение файла из вашего репозитория в git-lfs.

person Marina Liu    schedule 25.05.2017
comment
Но эта команда, похоже, обрезает репозиторий только локально, а не в удаленном репо. - person Devedse; 14.06.2017
comment
К вашему сведению, ни git fsck --full, ни git fsck --dangling не показывают висячие коммиты в .git/lost-found, вам нужно запустить git fsck --lost-found, чтобы убедиться, что нигде нет висячих коммитов. - person xuancong84; 12.05.2020