On Wed, Nov 11, 2009 at 5:28 AM, Pascal Obry <pascal@xxxxxxxx> wrote: >> Avery wrote: >> Is d2cf08bb67e4b7da33a250127aab784f1f2f58d3 a valid revision? (git >> log d2cf08bb67e4b7da33a250127aab784f1f2f58d3). > > No. Well, that's bad news. Does "git log --all --parents | grep d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer to it? 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. >> You could try using git bisect to figure out which exact commit to >> git.git created the problem. > > I wanted to avoid that :) Anyway, here is the culprit: > > commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d > Author: Adam Brewster <adambrewster@xxxxxxxxx> > Date: Tue Aug 11 23:14:27 2009 -0400 > > svn: allow branches outside of refs/remotes [...] > > But frankly I'm no expert on Perl... I fear that I won't be able to debug > that! If you retrieve the latest version of git and then git revert the above commit, does that fix the problem, at least? 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? Avery -- 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