5

We are working in a group and commiting data daily in large numbers due to which .git folder is becoming very heavy in size. And while performing the pull command on our system, it takes a lot of time due to heavy size of .git folder. How can we clean or reduce the size of this git repo ?

tkausl
  • 13,686
  • 2
  • 33
  • 50
samnit
  • 139
  • 1
  • 7
  • https://www.atlassian.com/blog/git/handle-big-repositories-git should be helpful – sauerburger Aug 24 '17 at 14:29
  • Tried [garbage collection](https://stackoverflow.com/questions/2116778/reduce-git-repository-size)? – phd Aug 24 '17 at 18:42
  • Step number one is to figure out if you really need “version control” or perhaps “synchronization” or “keep last 100 changes”. Git only directly implements the first as far as the repo itself is concerned, but you can get “last 100 changes” with a shallow clone. – Guildenstern May 06 '23 at 12:18

2 Answers2

0

You need to determine if there is something inherently big in your repository --like too many big binary files-- or if a garbage collection will fix it.

Do a garbage collection, see how big your repo is.

If that doesn't fix it, look at the Atlassian link that @sauerburger provided, or do some other googling based on what you find there.

(The details of these steps are intentionally left as an exercise for the user.)

Mort
  • 3,379
  • 1
  • 25
  • 40
0

If most of the file size is taken up by old commits in the .git folder, rather than current files, what you can do is rebase a specific recent commit as the root, keeping all files and commits from that point on but getting rid of older history.

Make sure to back everything up first!

Quoting this answer (https://stackoverflow.com/a/24153726/7070218):

One way to do this is here, assuming your current work is called branchname. I like to use a temp tag whenever I do a large rebase to double-check that there were no changes and to mark a point I can reset back to if something goes wrong (not sure if this is standard procedure or not but it works for me):

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

To get rid of the old branch you'll need to delete all tags and branch tags on it; then

git prune
git gc

will clean it from your repo.

Note that you'll temporarily have two copies of everything, until you have gc'd, but that is unavoidable; even if you do a standard squash and rebase you still have two copies of everything until the rebase finishes.

brendon-ai
  • 517
  • 3
  • 7
  • 20
  • 2
    This procedure may have made sense at one time, but now it's just a manual way to imitate "shallowing" of a repo. A true shallow repo (e.g. once created by using the `depth` parameter to `clone`) is better, in fact, because it preserves commit ID's (which can be useful for many reasons, especially if you keep an archive of the original history). Also, as an aside, this business about having "two copies of everything" after a rebase is incorrect; that's not how git stores things. – Mark Adelsberger Aug 24 '17 at 19:21