0

There are several very related question already on stackoverflow (a few are linked below) but I could not solve my particular problem.

I share a repository with Co-workers who have pushed huge datafiles/images that increased the size of the remote repository up to 14 GB. Later on, these files got deleted using just rm filename which resized the local repositories to a reasonable size. However, when I check online, the repository's size is still 14 GB.

What I tried to reduce the repositories size is what is suggested here:

git reflog expire --expire=now --all
git gc --aggressive --prune=now

but that only affected my local repository's size.

The answers here did not help either since the files were not deleted on my own computer but on the Co-workers' ones.

What I have not tried yet, but which might work is to delete all the commit history as described here . However, I would actually keep all the commit history and just get rid of all the garbage created by rm filename on machines that are not my own.

Is there any solution to this (getting rid of garbage created on other local machines to decrease the size of the remote repository) without removing all the commit history?

EDIT:

In @torek's link in the comments, I found a command to get rid of commits related to a certain file. I then tried to get rid of all commits that are about images e.g. .png. I used the following command:

git filter-branch --tree-filter 'rm -f *.png' HEAD

However, I then get the message:

WARNING: Ref 'refs/heads/master' is unchanged

How would I use it correctly?

Community
  • 1
  • 1
Cleb
  • 25,102
  • 20
  • 116
  • 151
  • These large files are now in *everyone*'s repositories (everyone who picked up the changes anyway). To get rid of them, *everyone* must coordinate. See http://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository. How painful it will all be depends on how many later commits refer to the earlier commits that contain the huge files: every such commit must be replaced. – torek Nov 10 '16 at 11:16
  • @torek: Thanks for the link! Seems there is a way to get rid of al commits in which e.g. .png are mentioned. This might already be sufficient. – Cleb Nov 10 '16 at 11:24
  • It might: but the thing is that if you discard a commit, all *subsequent* commits acquire new hash IDs. Everyone must pick up the new commits and stop using the old ones. (The old ones will still be in everyone's repositories, until they are no longer referenced and expire. By default that takes at least a month, although you can manually expire reflogs and then prune objects younger than 14 days old.) – torek Nov 10 '16 at 13:42
  • @torek: ok, so maybe it is then the best to copy the repository to a new one as described [here](http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/). What would you recommend? – Cleb Nov 10 '16 at 14:07
  • I've never actually used it, but those who have, say that using "BFG" is much easier than using filter-branch. – torek Nov 10 '16 at 14:16
  • @torek: A colleague tried it but seems it only affected the local repository; the remote one was still the same size. But maybe I will give it a try as well. – Cleb Nov 10 '16 at 14:22
  • All Git operations work only on the local repository, with the exception of `git fetch` and `git push` (and to a much more limited extent, `git ls-remote` and a few options within `git remote`). Until you push the results, you will never update any references (basically, branch and tag names) in any other repository. (Another repository can *fetch* your results, then use those to affect their references.) – torek Nov 10 '16 at 14:24

0 Answers0