Pascal Obry <pascal@xxxxxxxx> wrote: > Avery, > >> Well, that's bad news. Does "git log --all --parents | grep >> d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer >> to it? > > No. Weird... >> It sounds a bit like your git-svn thinks something maps on to that >> commit id, but a previous 'git gc' or something has thrown it away. >> However, that doesn't explain why earlier git versions don't have this >> problem. > > Maybe, but that would be a quite annoying bug! >> If you retrieve the latest version of git and then git revert the >> above commit, does that fix the problem, at least? > > I cannot, this does not revert cleanly and I don't know how to properly > resolve this conflict. I'm no Perl expert! > > But reverting using the version just before fixes this problem. That should rule out filesystem corruption... >> Is it possible you have some weird branches outside of the >> refs/remotes tree (either in .git itself, or in .git/refs/*) that you >> forgot about, and which the new version of git-svn is finding somehow? > > I do not see something under .git/refs/* (only empty directories). > > The project has been imported using something like this: > > $ git svn clone --prefix=svn/ svn+ssh://server/path \ > --revision=580:HEAD \ > --trunk=trunk/project \ > --tags=tags/project \ > --branches=branches/project \ > --branches="branches/global/*/project" project It looks like you didn't use any of the weird[1] options that make it unsafe to clobber the rev_maps. Can you try removing all the .rev_map.* files in $GIT_DIR/svn and running "git svn fetch" to rebuild them? [1] --no-metadata, --use-svm-props -- Eric Wong -- 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