We have a Git repo with 7 contributing developers with over 2.5 years of history and about 10,000 commits. We use Assembla to push and pull from. When we add new developers cloning the repo to their dev computers takes almost an hour.
I'm not sure if this is the proper terminology, but our goal is to "shrink" the repo by "cutting/snipping" off the first 1.5 years worth of commits and keeping only the latest year of history. We want to keep a "backup" copy of the entire repo, whether as a separate repo or maybe a branch? We'd like to repeat this in the future an possible merge the initial split with the new split when needed, but I'm not sure if this is possible. If there is a way to have all the history on a separate branch and just keep the master
branch with only the history for the last year, that would be great, but let me know of possible pros and cons.
I don't know of all the possibilities/options we have which is why I am here. I read something about patches
but I'm not sure if that truly is what I need or if there is something better/easier. What are you guys doing to take care of an issue like this, including pros and cons? Keep in mind, I still need every developer to continue to push and pull, preferably staying on the master
branch.
Thanks in advance!
The best step-by-step instructions can be found on the Git SCM historical blog post "Replace Kicker" or in the Git book's chapter on "Replace".
The short summary is this:
git branch history
hash.git commit-tree
.history
commits onto your new base.master
branch up to the server.git replace
to re-connect the history together.The original post explains it much better with pictures.
When dealing with complex histories involving merges, this may not work well, depending on how well git rebase --onto
works with --preserve-merges
. You should obviously test well before proceeding.
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