Hi, On Fri, 8 Aug 2008, Johannes Schindelin wrote: > On Fri, 8 Aug 2008, Shawn O. Pearce wrote: > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > my auto gc kicked in, and shows this: > > > > > > fatal: corrupt packed object for 2c1e128aa51e3a64bd61556c0cd488628b423ccf > > > error: failed to run repack > > > > > > Fortunately, I have the uncorrupted object somewhere else. So I copy the > > > single object as a loose one, and all is fine. Right? > > > > > > Wrong. > > > > > > Repack still picks up the corrupt object instead of the good one. What's > > > the best way out? > > > > Use a 1.6.0 rc? Nico I thought fixed this in 1.6 to automatically > > try and find another copy of an object if the first copy considered > > for inclusion into the pack was corrupt. > > Thanks for the quick reply, but no joy (You should know me better than > that ;-) : > > $ git --version > git version 1.6.0.rc1.112.gebbe4 Just for bullocks, I gave it a try with git version 1.6.0.rc1.141.g0d7ea. That is rc2+26 patches, in case you are interested. Unfortunately, each test costs me 630.25user 19.74system 22:01.43elapsed 49%CPU (0avgtext+0avgdata 0maxresident)k 7533688inputs+3154520outputs (55275major+2011583minor)pagefaults 0swaps (including the inability to work properly because of all the swapping) which is not really nice, as the corrupt packed object occurs during the last 20% of the _writing_ phase of 60104 objects. Oh, and they are big objects. The corrupt one is 65 megabyte, for example. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
