On Thu, Aug 27, 2009 at 23:07, Nico Weber<tha...@chromium.org> wrote: > > I accidentally fixed the problem by running something like > > rm -rf .git/svn/ > git svn fetch;
This one is most likely, the next one being the git pull. > ... git merge trunk > git merge refs/remotes/origin/trunk > git checkout -f HEAD This command should do nothing, unless you removed the files outside .git directory (also called "working tree"). It is the same as "git reset --hard" (HEAD will be assumed): get tree from the revision pointed by HEAD and write them in the file system. > git pull This may have cured you of the problem too, by fetching some data from the parent repository. It may have been enough to never access the problematic pack at its problematic place anymore. > . Not sure what fixed it, but pulling works again. Yay, I guess, but > of course I fixed it about 2 minutes before someone asked me to send a > dtrace to the git mailing list :-/ There is also "git fsck --full", which can tell more about about where problems located, so you can try to look at backups or parent/sibling repositories for corrupted data. It is generally enough to just copy the objects (files from .git/objects/?? and .git/objects/pack/*, even blindly all of them) into the problematic repository. You can repack (either "git gc" or "git repack -ad") later to get rid of the data not referenced by your particular set of references. But in all cases, if you have something which looks like a repository corruption, developers at g...@vger.kernel.org would like to know about it. Thank you. P.S. Oh, great. Now I'm discovered :) --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---