Menu
I've just run git gc on my local repository to do some regular clean-up. Today for the first time, it failed. Here's what I've done: (Windows 7)
C:\Source\TxTranslation>git gc Counting objects: 880, done. Delta compression using up to 8 threads. Compressing objects: 100% (540/540), done. Writing objects: 100% (880/880), done. Total 880 (delta 504), reused 589 (delta 333) rm: cannot unlink `pack-18179305b5b5dbdaf059e4ded50b736ab93e220c.pack': Permission denied C:\Source\TxTranslation>git gc Counting objects: 880, done. Delta compression using up to 8 threads. Compressing objects: 100% (369/369), done. Writing objects: 100% (880/880), done. Total 880 (delta 504), reused 880 (delta 504) mv: cannot move `/c/Source/TxTranslation/.git/objects/pack/pack-3002d22690e007a4205f6ecfa19d6e93296fdd78.pack' to `/c/Source/TxTranslation/.git/objects/pack/old-pack-3002d22690e007a4205f6ecfa19d6e93296fdd78.pack' error: failed to run repack I can retry it as often as I want, I always get the second output again. The "permission denied" error above is nonsense. I believe it's a common spurious error that I see on many Windows systems these days. It may be coming from virus scanners that keep files open so that they can't be deleted immediately. That leads to all sorts of issues but apparently can't be avoided.
Is this a problem? Is something broken? I absolutely don't understand what those message mean to me. Browsing the log with diffs still works. What could I do to fix that problem? (Luckily I have pushed everything to Github just before, so I could simply re-clone it, but I'd like to try fixing it first, in case it happens again.)
300
DESCRIPTION. This command is used to combine all objects that do not currently reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack.
See gc. auto below for how to disable this behavior. Running git gc manually should only be needed when adding objects to a repository without regularly running such porcelain commands, to do a one-off repository optimization, or e.g. to clean up a suboptimal mass-import.
You should consider running git gc manually in a few situations: If you have just completed a git filter-branch . Recall that filter-branch rewrites many commits, introduces new ones, and leaves the old ones on a ref that should be removed when you are satisfied with the results.
git gc --prune=now removes the commits themselves. Attention: Only using git gc --prune=now will not work since those commits are still referenced in the reflog. Therefore, clearing the reflog is mandatory. Also note that if you use rerere it has additional references not cleared by these commands.
As it turned out, Visual Studio had a lock on some of Git's files. Closing Visual Studio resolved the issue.
FTR, I'm using the Git source control provider (in the last usable version 0.6.4) in VS2010. Maybe this is part of the cause.
172
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
