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
-~----------~----~----~----~------~----~------~--~---
