Нажмите на источник после истечения срока действия reflog и gc prune

Question

Я удалил некоторые недоступные и висящие коммиты в моем локальном репо, используя

git fsck --unreachable --dangling --no-reflogs
git reflog expire --expire=now --all
git gc --prune=now

Но я обнаружил, что удаленные коммиты все еще доступны на источнике (если быть точным, GitHub).

Я старался git push --force но он не синхронизирует изменения с источником. Как принудительно синхронизировать изменения в источнике (удалить удаленные коммиты также и из удаленного)?

Это похожий вопрос без ответа:

Область действия gc prune и git reflog expire и соответствующие настройки

Answer 1

Краткая форма

Вы не можете диктовать, как удаленный хранит свои данные от клиента.

Более длинная форма

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

Во-вторых, Git работает, передавая объекты. Хитрость в том, что речь идет только о доступных объектах по проводу. То есть должен быть путь от ссылки (ветви или тега) к объекту в истории. Если указанный объект недоступен, Git откажется передать его клиенту, даже если он находится в базе данных объектов. Обратная сторона этого заключается в том, что все, что вы делаете локально, без изменения или обновления ссылки, не может быть передано между локальным и удаленным репозиториями. Вы не можете сказать "синхронизировать мой макет базы данных локальных объектов с удаленным". Вы можете только сказать "сделать объекты, доступные между моими локальными и удаленными одинаковыми".

Наконец, то, как вещи представляются в GitHub, и удаляются ли объекты в конечном итоге, полностью зависит от GitHub. Зак Холман выступил с докладом о некоторых вещах, происходящих за кадром. Я предполагаю, что в какой-то момент они запускают что-то в фоновом режиме, чтобы обрезать свисающие объекты, но с точки зрения удаленного доступа это действительно не имеет значения - люди не могут получить доступ к объектам, на которые нет ссылок. Единственная проблема - размер. Я знаю, что они делают какое-то сокращение, потому что я урезал репозитории в прошлом и уменьшил их размер (вы можете проверить это, посмотрев на элемент size с помощью вызова API. Вы можете попробовать это в качестве примера: https://api.github.com/repos/jszakmeister/vimfiles).

Если ваша цель - уменьшить размер репозитория, поскольку вы отметили слишком большие объекты, взгляните на страницу удаления конфиденциальных данных в разделе справки GitHub. Это в равной степени относится и к большим файлам, которые вы хотите удалить навсегда (простое удаление с помощью коммита не удаляет их полностью из истории).

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