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: Tue, 02 Oct 2012 15:21:27 -0700	[thread overview]
Message-ID: <7vy5jo5xco.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7v4nmc7fmz.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Tue, 02 Oct 2012 14:01:08 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> The last piece to expect "error in tag.*broken links" in the output
> is wrong.  Probably we should remove the misguided check and end
> it with "test_must_fail git fsck --tags".

I think this should suffice.

When we check tag T first, we make a mental note on X that is
referred by T that X must be of a certain type, but we do not bother
recording _why_ we decided X must be of the type (e.g. "because tag
T asks it to be").  So when we check T and later check X, the only
thing we know is that we expected X to be commit but it actually is
blob.  Exactly the same type of issue can arise for a blob that is
pointed by a tree or a tree that is pointed by a commit.  If a tree
records a reference to a commit but with 100644 mode bits, we may
either say tree is broken (when we have already seen the referent
and know it is a commit), or the referent is broken (when we saw the
tree first and expect the referent to be a blob).

-- >8 --
Subject: [PATCH] t1450: the order the objects are checked is undefined

When a tag T points at an object X that is of a type that is
different from what the tag records as, fsck should report it as an
error.

However, depending on the order X and T are checked individually,
the actual error message can be different.  If X is checked first,
fsck remembers X's type and then when it checks T, it notices that T
records X as a wrong type (i.e. the complaint is about a broken tag
T).  If T is checked first, on the other hand, fsck remembers that we
need to verify X is of the type tag records, and when it later
checks X, it notices that X is of a wrong type (i.e. the complaint
is about a broken object X).

The important thing is that fsck notices such an error and diagnoses
the issue on object X, but the test was expecting that we happen to
check objects in the order to make us detect issues with tag T, not
with object X.  Remove this unwarranted assumption.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t1450-fsck.sh | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 5b79c51..9c64eef 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -177,9 +177,7 @@ test_expect_success 'tag pointing to something else than its type' '
 	test_when_finished "remove_object $tag" &&
 	echo $tag >.git/refs/tags/wrong &&
 	test_when_finished "git update-ref -d refs/tags/wrong" &&
-	test_must_fail git fsck --tags 2>out &&
-	cat out &&
-	grep "error in tag.*broken links" out
+	test_must_fail git fsck --tags
 '
 
 test_expect_success 'cleaned up' '
-- 
1.8.0.rc0.54.g771a61b

  reply	other threads:[~2012-10-02 22:21 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
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 [this message]
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=7vy5jo5xco.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).