Avery,
Well, that's bad news. Does "git log --all --parents | grep
d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer
to it?
No.
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.
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
Nothing fancy. The git-svn mirrors is updated every night using Git
1.6.4 without problem.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
--
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