3

I have added and subsequently removed a binary file (path "ACHThesis/preamble.fmt") from my git repository using the method as outlined in Update a development team with rewritten Git repo history, removing big files . As suggested by the gitbook I also ran 

rm -Rf .git/refs/original
rm -Rf .git/logs/
git gc

Indeed, the large file no longer appears to be referenced by any commits, as shown by 

git log --pretty=oneline -- ACHThesis/preamble.fmt
(no output)

However, when I look at the biggest file in the repository with 

git verify-pack -v .git/objects/pack/pack-6136e671bba3772bdf40ba3306aa249d654
0a117.idx | sort -k 3 -n | tail -1
e4cf847b6815c9833d04f9a449286112718a3926 blob   6771554 2414394 6791333

and look at its identity

$ git rev-list --objects --all | grep e4cf
e4cf847b6815c9833d04f9a449286112718a3926 ACHThesis/preamble.fmt

the binary file is clearly still present. How can I remove it ?

Questions I have looked at but which have not helped

Community
  • 1
  • 1
ach
  • 195
  • 5

3 Answers3

2

Short Answer

The file will go away on its own eventually. It will never be sent over the network since it is no longer reachable from any of your branches. If you can live with the disk space for a while, leave it alone.

Medium Answer

git clone the repository to another location on disk and rm the original repository.

Long Answer

See this question.

Community
  • 1
  • 1
Peter Lundgren
  • 8,787
  • 2
  • 26
  • 21
0

I think git gc only remove objects older than 2 weeks by default. Maybe you can try to rerun it with the --prune option

git gc --prune=now
cexbrayat
  • 17,772
  • 4
  • 27
  • 22
  • 1
    I ran this as well as some of the other commands in http://stackoverflow.com/questions/10656794/why-do-large-files-still-exist-in-my-packfile-after-scrubbing-them-with-filter as well, file persists. – ach May 16 '13 at 10:25
0

The "solution" that I ended up with was to clone the repository after I had performed all the filter-branches -- the cloned repo did not have the removed binaries upon packing.

I am sure there is a better solution, though, so I shall leave this as 'unanswered' for a couple more days in the hope someone git-savvy comes along.

ach
  • 195
  • 5