That usually means a process is still using that specific file (still has an handle on it)
(on Windows, ProcessExplorer is good at tracking that kind of process)
Try closing your other programs, and try again your git pull.
Note that you have an alternative with the GIT_ASK_YESNO variable.
Update January 2019:
That should be even more fixed, with Git 2.21 (Q1 2019), as "git gc" and "git repack" did not close the open packfiles that they found unneeded before removing them, which didn't work on a platform incapable of removing an open file.
This has been corrected.
See commit 5bdece0 (15 Dec 2018) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 5104f8f, 18 Jan 2019)
gc/repack: release packs when needed
On Windows, files cannot be removed nor renamed if there are still handles held by a process.
To remedy that, we introduced the close_all_packs() function.
Earlier, we made sure that the packs are released just before git gc is spawned, in case that gc wants to remove no-longer needed packs.
But this developer forgot that gc itself also needs to let go of packs, e.g. when consolidating all packs via the --aggressive option.
Likewise, git repack -d wants to delete obsolete packs and therefore needs to close all pack handles, too.
Update January 2016
That should be fixed in Git 2.8 (March 2016) (and see Git 2.19, Q3 2018 below)
See commit d562102, commit dcacb1b, commit df617b5, commit 0898c96 (13 Jan 2016) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 3c80940, 26 Jan 2016)
fetch: release pack files before garbage-collecting
Before auto-gc'ing, we need to make sure that the pack files are released in case they need to be repacked and garbage-collected.
Many codepaths that run "gc --auto" before exiting kept packfiles mapped and left the file descriptors to them open, which was not friendly to systems that cannot remove files that are open.
They now close the packs before doing so.
That fixes git-for-widows issue 500.
Looking at the test used to validate that new approach, a possible workaround (since Git 2.8 is not yet out) would be to raise artificially gc.autoPackLimit.
git config gc.autoPackLimit 10000
git fetch
git config gc.autoPackLimit 50 # default value
git 2.8.4 (June 2016) does mention issue 755 which should also alleviate the issue (commit 2db0641):
Make sure temporary file handles are not inherited by child processes
Actually, git-for-windows issue 500 mentioned above is really fixed with Git 2.19, Q3 2018.
See "Git - Unlink of file .idx and .pack failed (The only process owned handle to this file is git.exe)"
