Как уменьшить размер раздутого репозитория Git, неинтерактивно сжимая все коммиты, кроме самых последних?

Оригинальный постер комментирует:

git tag temp

git checkout 10004
git checkout --orphan new_root
git commit -m "set new root 10004"

git rebase --onto new_root 10004 branchname

git diff temp   # verification that it worked with no changes
git tag -d temp
git branch -D new_root

git prune
git gc

Самое быстрое подсчет времени реализации почти наверняка будет с графтами и filter-branch, хотя вы могли бы добиться более быстрого выполнения с помощью commit-tree отработка последовательности rev-list вывод.

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

Полезная нагрузка здесь, работающая с вашей фотографии,

echo `git rev-parse H; git rev-parse A` > .git/info/grafts  
git filter-branch -- --all

_{Документация для git rev-parse и git filter-branch.}

Ветвь фильтра очень тщательно следит за тем, чтобы ее можно было восстановить после сбоя в любой момент, что, безусловно, является самым безопасным .... но это действительно полезно только тогда, когда восстановление путем простого повторения не будет быстрее и проще, если дела пойдут не так. Поскольку сбои редки, а перезапуск обычно дешев, нужно выполнить не «безопасную», но очень быструю операцию, которая почти наверняка сработает. Для этого лучший вариант здесь - сделать это на tmpfs (ближайшим известным мне эквивалентом в Windows будет виртуальный диск, например ImDisk), который будет молниеносно работать и не затронет ваш основной репозиторий, пока вы не будете уверены, что получили нужные результаты.

Итак, в Windows скажем, что T:\wip находится на виртуальном диске, и обратите внимание, что клон здесь ничего не копирует. А также читать документы на git clone's --shared, изучите внутренности клона, чтобы увидеть реальный эффект, это очень просто.

# switch to a lightweight wip clone on a tmpfs
git clone --shared --no-checkout . /t/wip/filterwork
cd !$

# graft out the unwanted commits
echo `git rev-parse $L; git rev-parse $A` >.git/info/grafts
git filter-branch -- --all

# check that the repo history looks right
git log --graph --decorate --oneline --all

# all done with the splicing, filter-branch has integrated it
rm .git/info/grafts

# push the rewritten histories back
git push origin --all --force

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

Проблема XY

Обратите внимание, что у оригинального автора есть проблема XY, когда он пытается выяснить, как раздавить свои старые коммиты (т. проблема Y), когда его реальная проблема на самом деле заключается в попытке уменьшить размер своего репозитория Git (проблема X), all-commits-except-for-the-most-recent-ones#comment37275724_24153548">как я уже упоминал в комментариях:

Наличие большого количества коммитов не обязательно приведет к увеличению размера вашего репозитория Git. Git очень эффективно сжимает текстовые файлы. Вы уверены, что количество коммитов является реальной проблемой, которая приводит к большому размеру вашего репо? Более вероятным кандидатом является то, что у вас слишком много версий двоичных ресурсов, которые Git не сжимает так же хорошо (или вообще не сжимает) по сравнению с обычными текстовыми файлами.

Несмотря на это, для полноты картины я также добавлю альтернативное решение к ответу Мэтта Макнабба к проблеме Y.

Удаление (сотни или тысячи) старых коммитов

Как уже отмечалось в оригинальном постере, использование интерактивной перебазировки с флагом --root может быть непрактичным, когда есть много коммитов (исчисляемых сотнями или тысячами), особенно потому, что интерактивная перебазировка не будет эффективно работать на таком большом количестве из них. .

Как указал Мэтт Макнабб в своем ответе, одним из решений является использование ветки-сироты в качестве нового (раздавленного) корня, а затем перебазирование поверх него. Другое решение — использовать пару различных сбросов ветки для достижения того же эффекта:

# Save the current state of the branch in a couple of other branches
git branch beforeReset
git branch verification

# Also mark where we want to start squashing commits
git branch oldBase <most_recent_commit_to_squash>

# Temporarily remove the most recent commits from the current branch,
# because we don't want to squash those:
git reset --hard oldBase

# Using a soft reset to the root commit will keep all of the changes
# staged in the index, so you just need to amend those changes to the
# root commit:
git reset --soft <root_commit>
git commit --amend

# Rebase onto the new amended root,
# starting from oldBase and going up to beforeReset
git rebase --onto master oldBase beforeReset

# Switch back to master and (fast-forward) merge it with beforeReset
git checkout master
git merge beforeReset

# Verify that master still contains the same state as before all of the resets
git diff verification

# Cleanup
git branch -D beforeReset oldBase verification

# As part of cleanup, since the original poster mentioned that
# he has a lot of commits that he wants to remove to reduce
# the size of his repo, garbage collect the old, dangling commits too
git gc --prune=all

Параметр --prune=all для git gc гарантирует, что все висячие коммиты удаляются сборщиком мусора, а не только те, которые старше 2 недель, что является настройкой по умолчанию для git gc.