54

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.)

micstr
  • 5,080
  • 8
  • 48
  • 76
ygoe
  • 18,655
  • 23
  • 113
  • 210
  • *Permission denied*, it looks like you have some weird permissions problem with windows. – OneOfOne Sep 01 '13 at 21:46
  • 1
    Don't ignore the error message just because it seems "spurious" to you. Git is telling you exactly what is wrong: it was not allowed to unlink that file. Why that occurred is something we can't diagnose - maybe your permissions got messed up, maybe something else has a lock on that file. But dismissing the error message isn't going to get you anywhere. – Chris Hayes Sep 01 '13 at 21:49
  • So are you using a virus scanner that interferes with normal operation of programs? If so, get a better virus scanner. (Or, consider whether you *really* need one. Or, tell your virus scanner to avoid your git repository directories.) – Greg Hewgill Sep 01 '13 at 21:58
  • I'd already think that McAfee isn't exactly great, but is Avast neither? Anyway, how can I resolve the issue now? Is my repository broken beyond repair now, because I only get comments on other topics? – ygoe Sep 02 '13 at 06:45
  • This I saw from within a Jenkins job. :boom: It appears like some .git locks could have been leftover from other jobs. – macetw Mar 23 '22 at 15:45

8 Answers8

47

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.

ygoe
  • 18,655
  • 23
  • 113
  • 210
  • 2
    in my case it was eclipse ide – Subham Tripathi Jun 15 '16 at 03:21
  • 1
    The Microsoft Git provider in VS 2015 doesn't seem to cause this issue. I've gc'ed repositories many times while it was open and nothing happened. – ygoe Jun 15 '16 at 07:21
  • atom just caused this as well. – Omortis Mar 04 '18 at 18:16
  • In my case it was Sublime Merge. All these buggy apps really need to figure out what files they should and shouldn't be locking. – laurent Nov 24 '20 at 23:07
  • But closing the IDE can't be a feasible solution in a long run is it? Every time you commit you don't wanna be closing your IDE – xyf Mar 16 '23 at 18:01
  • @xyf The question is about `gc` not `commit`. And it's 10 years old and I haven't experienced this issue in years. Using VS 2022 and TortoiseGit. – ygoe Mar 16 '23 at 22:29
44

In my case git gc would fail to run repack after enumerating but it was successful when running with some additional options, git gc --aggressive --prune=now.

Jacob Lange
  • 1,299
  • 14
  • 22
  • 4
    This was it for me. All of my editors were closed and I was still getting repack failures. The additional options helped get things moving along. Thanks! – Aaron Hathaway Dec 13 '18 at 21:00
  • 18
    Unfortunately I still get the same error after trying `git gc --aggressive --prune=now` – Ryan Feb 24 '19 at 20:10
  • Using GIT GUI and pack failures were occurring. THe aggressive option listed here saved the day! – Ross Youngblood Mar 28 '19 at 19:35
  • 1
    That worked for me. I got this error after a reboot, with no open editors and with no processes locking git files. `git gc --aggressive --prune=now` did the trick. – Arialdo Martini Jul 04 '19 at 07:10
9

I got the same issue using eclipse . The was accessing git repository through Eclipse as well as git bash.

Solved by running the gc after closing eclipse

Environment

Windows 7

Git 1.8.4.mysysgit.0

Eclipse Kepler SR2

arunvg
  • 1,209
  • 1
  • 20
  • 31
5

If you were doing some other operation with git, or some git-related operation in a GUI, cancel the operation or close the error, and manually run a git gc, then try your operation again. Basically, on Windows, this message is an indication of contention between the git command line client and some other program.

In my case, the repack had been triggered automatically as part of a git pull. When I got the error, after ruling out a permission issue with a quick sanity check that none of the things that would be launching git processes (IDE, git bash, git GUI) would be running elevated, I went to Process Explorer to find out what process had the file open (Find -> File Handle or DLL), and it found a git.exe that was a parent of the other git.exe process. I'm guessing that there are some locking assumptions in the automatic repack code that aren't appropriate on Windows, where, by default, opening a file puts an exclusive read/write lock on the file at the OS level.

That was with

$ git --version
git version 1.9.2.msysgit.0
rakslice
  • 8,742
  • 4
  • 53
  • 57
4

Hope this helps others.

In my case I found that Tortoise Git process was the culprit for locking files. Terminating the process allowed me to git gc

Dave Hogan
  • 3,201
  • 6
  • 29
  • 54
3

In my case a running IISExpress instance was to blame.

Mark Brownsword
  • 2,287
  • 2
  • 14
  • 23
2

This happened to me even AFTER I closed my solution in Visual Studio, but was resolved when I finally closed VS. I was NOT using the git source control extension.

mfugel
  • 41
  • 1
  • 4
0

For what it's worth none of the solutions above worked for me. My problem was specific to my workspace and yes, as mentioned by others sometimes you don't have any other choice but to just wipe/backup your local .git and start over.

However, if you find the wipe procedure to be a bit too intense I suggest isolating your purge to the problematic objects. In my case the problematic options were of the following sort:

bad sha1 file: .git/objects/06/c224b111bd7e87befc69be51541f4ab9352dd5.utf8
bad sha1 file: .git/objects/0c/cd0a767b81cd3facfc501a2bf1541f5988e8fc.utf8
bad sha1 file: .git/objects/0f/3b8f190b96d142d84caee75445de5e2052da37.utf8
...

This was linked to problems that occured with the default encodings of my work machine WAY back when I started setting up my local repository. For me these object versions are obsolete and non-pertinent so I just removed them (consider a mv instead of rm if you don't like to live dangerously like me):

rm -rf .git/objects/*/*.utf8

Final note: don't be like me! RTFM. In my classic a**-backwards fashion, now that things are cleaned up and git gc is working as expected, I finally searched for the document that more thoroughly explains the files that I just obliterated. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

blackstrype
  • 451
  • 9
  • 14