On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote:
> I saw the problem first on pu, some time ago,
> but it dissappeared after cloning git.git into another directory.
> Now it appeared on next as well, so it's time to look a little bit deeper.
> This test case of t1450 fails:
> test_expect_success 'tag pointing to something else than its type' '
I can't reproduce this failure; I tried both pu or next, on Linux and OS
> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged
> Mac OS X:
> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
That seems very broken. That sha1 can have only one type, so OS X is
actually mis-parsing the object type? Weird. I would suggest a memory
error or race condition, but the test is valgrind-clean, and fsck should
not be threaded at all.
What does "git show 63499e4" show when the test has failed? If you
re-run "git fsck --tags", does it reproduce reliably (i.e., is it bogus
data that something wrote to the object db, or is it good data being
ruined during the reading process)?
> I reverted the last change in fsck.c (Use the streaming interface), but that
> doesn't help
> Looking into the trash directory and looking at the files, we can see that
> the .git/index is different
> between Linux and Mac OS X.
> Is there a good way to debug the index file?
git ls-files -s will dump the entries. But I'd expect them not to be
byte-equivalent, because the index will contain things like mtimes for
each entry, which will vary from run to run. Plus the error message
above indicates something much more broken.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html