Re: [PATCH v2] fsck: handle NULL return of lookup_blob() and lookup_tree()

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2017, 02:23 UTC
Message-ID: <xmqq8tgpypyl.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <6bbe21c0-024e-ceed-6076-25f2330e598d@web.de>

René Scharfe <l.s.r@web.de> writes:

> An error message is already shown by object_as_type(), which is called
> by the lookup functions.  The walk callback functions are expected to
> handle NULL object pointers passed to them, but put_object_name() needs
> a valid object, so avoid calling it without one.

Thanks for getting the details right ;-)

> +	blob_bin=$(echo $blob | hex2oct) &&
> +	tree=$(
> +		printf "40000 dir\0${blob_bin}100644 file\0${blob_bin}" |

Wow, that's ... cute.

> +		git hash-object -t tree --stdin -w --literally

Makes me curious why --literally is here. Even if we let check_tree() called from index_mem() by taking the normal path, it wouldn't complain the type mismatch, I suspect. I guess doing it this way is a future-proof against check_tree() getting tightened in the future, in which case I think it makes sense.

And for the same reason, hashing "--literally" like this patch does is a better solution than using "git mktree", which would have allowed us to avoid the hex2oct and instead feed the tree in a bit more human-readable way.

Thanks, will queue.

Show 11 quoted lines

> +	) &&
> +	commit=$(git commit-tree $tree) &&
> +	git update-ref refs/heads/type_mismatch $commit &&
> +	test_must_fail git fsck >out 2>&1 &&
> +	test_i18ngrep "is a blob, not a tree" out &&
> +	test_i18ngrep ! "dangling blob" out
> +'
> +
>  test_expect_success 'tag pointing to nonexistent' '
>  	cat >invalid-tag <<-\EOF &&
>  	object ffffffffffffffffffffffffffffffffffffffff