0

Ok, so I have this remote repository on bitbucket and and I didn't work with my local files for the last 6 months. Now, today, after a good amount of work, I try to commit and push my so missed code, the operation takes more than 30min and I cancel because it didnt progress at all(stuck at 99%). I'm surprised as it previously wasn't the case and was almost instantly.

  • So I check my application size: 660MB according to finder
  • The .git folder is 600MB
  • On the remote part, the repo is 178mb

I thought my local repo was somehow broken with too much large files, decided to run bfg, and it didn't find no blob higher than 1MB.

It's a symphony2 installation where the vendor folder is excluded.

This is an ongoing push 10 min Writing objects: 99% (532/533), 203.39 MiB | 249.00 KiB/s

I don't know what to do else. Any suggestions ?

delmalki
  • 1,326
  • 1
  • 13
  • 31
  • You can also look into removing any binary files you might have. Binaries can easily cause your repo to balloon in size. – Tim Biegeleisen Jan 26 '16 at 01:11
  • Thanks I squashed using `git reset --soft HEAD ~3 && git commit -m "squashing" && git push -f` and it took not even 1 second – delmalki Jan 26 '16 at 01:26

1 Answers1

1

Local size has nothing to do with remote size.
Every time you add a file to git (even if you don't ever commit it), a SHA-1 is generated and the file is stored inside your .git folder.

So basically you can have unlimited data storage under .git folder.

What you do have to check is the size of the .pack files. This is the actual data stored in git. All the content is stored in there.

If you want to reduce the size and remove all unused data:

# The "expire" subcommand prunes older reflog entries. 
# Entries older than expire time
git reflog expire --all --expire=now

# clean and re-pack the repository
git gc --aggressive --prune=now

This will remove all the expired content under your repo and will re-pack your pack files.

In some cases you have several pack file and this will optimize them as well.

--aggressive

Usually git gc runs very quickly while providing good disk space utilization and performance.

This option will cause git gc to more aggressively optimize the repository at the expense of taking much more time. The effects of this optimization are persistent, so this option only needs to be used occasionally; every few hundred changesets or so.

--prune=<date>

Prune loose objects older than date (default is 2 weeks ago, overridable by the config variable gc.pruneExpir). --prune=all prunes loose objects regardless of their age (do not use --prune=all unless you know exactly what you are doing.

Unless the repository is quiescent, you will lose newly created objects that haven’t been anchored with the refs and end up corrupting your repository). --prune is on by default.

Community
  • 1
  • 1
CodeWizard
  • 128,036
  • 21
  • 144
  • 167