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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



René Scharfe <l.s.r@xxxxxx> 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.

> +	) &&
> +	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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux