I have a repository that has grown too big to the point it has become unusable. Basically my repository is over 2GB and takes too long to clone. I now want to shrink it, but still be able to go back to some specific old versions... Shrinking will involve rewriting history, so i m fine with that. People with clones will have to rebase/cherrypick/copyfiles on top of new branch in new repo clone.
I think of it as a squash of unneeded old repository history. What I came up so far as a possible process for my case ( I miss some steps and I am still unsure this will do what I think ) is :
Is this doable / feasible without any conflicts ? Will this work in any kind of cases ( git commit tree can be pretty complex ) ? Any better solution to safely and automatically squash history ?
It seems to me this type of maintenance task is something that will happen for a long running project, so I'm assuming other big projects already used some type of solution. But I guess there could be an option to git init ( or another command ) that I am not aware of, to create a new repo from an old repo for this usecase ?
Update : I found a beginning of solution here : https://wincent.com/wiki/Editing,_amending,_or_squashing_the_root_commit_in_a_Git_repository But I would like to do this multiple times into my history, in a fully automatic way (ie without conflicts)...
You can clone just a part of the repo:
git clone --depth depth
This is called a shallow clone.
The was a post on the Atlassian blog a while ago that offers other strategies for dealing with a large repo.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With