Re: t1450-fsck (sometimes/often) failes on Mac OS X

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

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(-)