问题
(solved, see bottom of the question body)
Looking for this for a long time now, what I have till now is:
- http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/ and
- http://progit.org/book/ch9-7.html
Pretty much the same method, but both of them leave objects in pack files... Stuck.
What I tried:
git filter-branch --index-filter \'git rm --cached --ignore-unmatch file_name\'
rm -Rf .git/refs/original
rm -Rf .git/logs/
git gc
Still have files in the pack, and this is how I know it:
git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3
And this:
git filter-branch --index-filter \"git rm -rf --cached --ignore-unmatch file_name\" HEAD
rm -rf .git/refs/original/ && git reflog expire --all && git gc --aggressive --prune
The same...
Tried git clone trick, it removed some of the files (~3000 of them) but the largest files are still there...
I have some large legacy files in the repository, ~200M, and I really don\'t want them there... And I don\'t want to reset the repository to 0 :(
SOLUTION: This is the shortest way to get rid of the files:
- check .git/packed-refs - my problem was that I had there a
refs/remotes/origin/masterline for a remote repository, delete it, otherwise git won\'t remove those files - (optional)
git verify-pack -v .git/objects/pack/#{pack-name}.idx | sort -k 3 -n | tail -5- to check for the largest files - (optional)
git rev-list --objects --all | grep a0d770a97ff0fac0be1d777b32cc67fe69eb9a98- to check what are those files git filter-branch --index-filter \'git rm --cached --ignore-unmatch file_names\'- to remove a file from all revisionsrm -rf .git/refs/original/- to remove git\'s backupgit reflog expire --all --expire=\'0 days\'- to expire all the loose objectsgit fsck --full --unreachable- to check if there are any loose objectsgit repack -A -d- repackinggit prune- to finally remove those objects
回答1:
I can't say for sure without access to your repository data, but I believe there are probably one or more packed refs still referencing old commits from before you ran git filter-branch. This would explain why git fsck --full --unreachable doesn't call the large blob an unreachable object, even though you've expired your reflog and removed the original (unpacked) refs.
Here's what I'd do (after git filter-branch and git gc have been done):
1) Make sure original refs are gone:
rm -rf .git/refs/original
2) Expire all reflog entries:
git reflog expire --all --expire='0 days'
3) Check for old packed refs
This could potentially be tricky, depending on how many packed refs you have. I don't know of any Git commands that automate this, so I think you'll have to do this manually. Make a backup of .git/packed-refs. Now edit .git/packed-refs. Check for old refs (in particular, see if it packed any of the refs from .git/refs/original). If you find any old ones that don't need to be there, delete them (remove the line for that ref).
After you finish cleaning up the packed-refs file, see if git fsck notices the unreachable objects:
git fsck --full --unreachable
If that worked, and git fsck now reports your large blob as unreachable, you can move on to the next step.
4) Repack your packed archive(s)
git repack -A -d
This will ensure that the unreachable objects get unpacked and stay unpacked.
5) Prune loose (unreachable) objects
git prune
And that should do it. Git really should have a better way to manage packed refs. Maybe there is a better way that I don't know about. In the absence of a better way, manual editing of the packed-refs file might be the only way to go.
回答2:
I'd recommend using the BFG Repo-Cleaner, a simpler, faster alternative to git-filter-branch specifically designed for rewriting files from Git history. One way in which it makes your life easier here is that it actually handles all references by default (all tags, branches, stuff like refs/remotes/origin/master, etc) but it's also 10-50x faster.
You should carefully follow these steps here: http://rtyley.github.com/bfg-repo-cleaner/#usage - but the core bit is just this: download the BFG's jar (requires Java 6 or above) and run this command:
$ java -jar bfg.jar --delete-files file_name my-repo.git
Any file named file_name (that isn't in your latest commit) will be will be totally removed from your repository's history. You can then use git gc to clean away the dead data:
$ git gc --prune=now --aggressive
The BFG is generally much simpler to use than git-filter-branch - the options are tailored around these two common use-cases:
- Removing Crazy Big Files
- Removing Passwords, Credentials & other Private data
Full disclosure: I'm the author of the BFG Repo-Cleaner.
回答3:
I found this to be quite helpful with regards to removing a whole folder as the above didn't really help me: https://help.github.com/articles/remove-sensitive-data.
I used:
git filter-branch -f --force \
--index-filter 'git rm -rf --cached --ignore-unmatch folder/sub-folder' \
--prune-empty --tag-name-filter cat -- --all
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now
回答4:
I was trying to get rid of a big file in the history, and the above answers worked, up to a point. The point is: they don't work if you have tags. If the commit containing the big file is reachable from a tag, then you would need to adjust the filter-branches command thusly:
git filter-branch --tag-name-filter cat \
--index-filter 'git rm --cached --ignore-unmatch huge_file_name' -- \
--all --tags
回答5:
See: How do I remove sensitive files from git’s history
The above will fail if the file does not exist in a rev. In that case, the '--ignore-unmatch' switch will fix it:
git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch <filename>' HEAD
Then, to get all loose objects out of the repostiry:
git gc --prune='0 days ago'
回答6:
You have various reasons for a still large git repo size after git gc, since it does not remove all loose objects.
I detail those reasons in "reduce the git repository size"
But one trick to test in your case would be to clone your "cleaned" Git repo and see if the clone has the appropriate size.
(' "cleaned" repo ' being the one where you did apply the filter-branch, and then gc and prune)
回答7:
This should be covered by the git obliterate command in Git Extras (https://github.com/visionmedia/git-extras).
git obliterate <filename>
回答8:
I had the same problem and I found a great tutorial on github that explain step by step how to get rid of files you accidentally committed.
Here is a little summary of the procedure as Cupcake suggested.
If you have a file named file_to_remove to remove from the history :
cd path_to_parent_dir
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch file_to_remove' \
--prune-empty --tag-name-filter cat -- --all
来源：https://stackoverflow.com/questions/2164581/remove-file-from-git-repository-history