git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: t1450-fsck (sometimes/often) failes on Mac OS X
Date: Wed, 19 Sep 2012 11:30:48 -0700	[thread overview]
Message-ID: <7va9wlhnl3.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <5059ED25.9090002@web.de> ("Torsten Bögershausen"'s message of "Wed, 19 Sep 2012 18:04:53 +0200")

Torsten Bögershausen <tboegi@web.de> writes:

>>> Linux:
>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit
>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
>>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object
>>>
>>> Mac OS X:
>>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
>>> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing

Interesting difference.

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

"is a blob, not a commit" is likely to come from validating of the
tag 66f6581d that presumably point at 63499e4; it reads the tag,
learns the name of the object that is tagged and the type of it,
remembers that the object pointed at (which it hasn't and is going
to validate next) _must_ be a commit (because tag says so) and then
realizes when it reads 63499e4 it is a blob and barfs.

And that is what _should_ happen in that test.  It crafts a
malformed tag that points at a blob and claims that it is a commit.
The test makes sure fsck catches that, and it does.

On the other hand, "is a commit, not a blob", unless you have a tag
that directly points at a blob, is more likely to come from
validating some tree object.  It reads the tree, learns the name of
the object contained in the tree and infers the type of that object
from the mode bits in the tree (100644 or 100755 would mean the
object must be a blob), goes on to validate that object and realizes
it is a commit and barfs.

It is veriy unusual to get, even on two different platforms, both
messages for the same object.

Could it be that you have i18n on "Object %s is a %s, not a %s" with
a wrong .po file that swaps the latter two parameters in the output?

>> What does "git show 63499e4" show when the test has failed?

Was this question ever answered (I would prever "cat-file -t"
followed by "cat-file <type>" instead of "show" for things like
this)?  It should show that it is a blob whose contents is "blob\n".

> Checking tag 66f6581d549f70e05ca586bc2df5c15a95662c36
> Checking commit 134756353796a5439d93586be27999eea3807a34
> Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit,
> not a blob
> error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing
> Checking tree bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7
> Checking commit c9145d6720f85544cc4bb6009a2e541660aa156b
> Checking tree c9176b0dd1a95c80ad8de21784b1eeffd3681f49
> Checking blob f719efd430d52bcfc8566a43b2eb655688d38871
> Checking cache tree
> Checking connectivity (32 objects)
> Checking 63499e4ea8e096b831515ceb1d5a7593e4d87ae5
> Checking 66f6581d549f70e05ca586bc2df5c15a95662c36
> Checking c9145d6720f85544cc4bb6009a2e541660aa156b
> Checking c9176b0dd1a95c80ad8de21784b1eeffd3681f49
> Checking 134756353796a5439d93586be27999eea3807a34
> Checking 5626abf0f72e58d7a153368ba57db4c673c0e171
> Checking f719efd430d52bcfc8566a43b2eb655688d38871
> Checking bd04fbdc74c1ad468ee1cc86d49860490ab3e6c7
> ===========
>
>
> diff failed passed
> diff out ../../../git.next/t/trash_directory.t1450-fsck2_120912_205305/out
> 17a18,20
>> Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
>> Checking blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5
>> error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit

This is the correct behaviour.

> 18a22,23
>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links
>> error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object

This too.

> 20,22d24
> < Checking blob 5626abf0f72e58d7a153368ba57db4c673c0e171
> < error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob
> < error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing

  reply	other threads:[~2012-09-19 18:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-14 12:21 t1450-fsck (sometimes/often) failes on Mac OS X Torsten Bögershausen
2012-07-15  9:08 ` Jeff King
2012-07-15 13:03   ` Torsten Bögershausen
2012-09-19 16:04   ` Torsten Bögershausen
2012-09-19 18:30     ` Junio C Hamano [this message]
2012-09-19 20:23       ` Torsten Bögershausen
2012-10-02 16:06       ` Torsten Bögershausen
2012-10-02 21:01         ` Junio C Hamano
2012-10-02 22:21           ` Junio C Hamano
2012-10-03 19:37             ` Torsten Bögershausen
2012-07-16  7:57 ` Thomas Rast
2012-07-16 16:06   ` Torsten Bögershausen
2012-07-28 15:43     ` Heiko Voigt
2012-07-28 16:00       ` Thomas Rast

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7va9wlhnl3.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).