Am 16.04.2015 um 12:03 schrieb Andreas Mohr: > Hi all, > > over the years I've had the same phenomenon with various versions of msysgit > (now at 1.9.5.msysgit.0, on Windows 7 64bit), so I'm now sufficiently > confident of it being a long-standing, longer-term issue and thus I'm > reporting it now.
(CC'ing msysgit) Hi Andreas, > Since I'm doing development in a sufficiently rebase-heavy manner, > I seem to aggregate a lot of objects. > Thus, when fetching content I'm sufficiently frequently greeted with > a git gc run. > This, however, does not work fully reliably: > > Auto packing the repository for optimum performance. You may also > run "git gc" manually. See "git help gc" for more information. > Counting objects: 206527, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (27430/27430), done. > Writing objects: 100% (206527/206527), done. > Total 206527 (delta 178632), reused 206527 (delta 178632) > Unlink of file > '.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.pack' > failed. Should I try again? (y/n) n > Unlink of file > '.git/objects/pack/pack-ab1712db0a94b5c55538d3b4cb3660cedc264c3c.idx' failed. > Should I try again? (y/n) n > Checking connectivity: 206527, done. > > A workable workaround for this recurring issue > (such a fetch will fail repeatedly, > thereby hampering my ability to update properly) > is to manually do a "git gc --auto" > prior to the fetch (which will then succeed). I've never had this issue. The error message from unlinking the file means that someone is still accessing the file and thus it can not be deleted (due to the implicit file locking on windows). Can you reproduce the error reliably? Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
