Re: [PATCH 0/8] Improvements for reading object info

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> This series has a conflict with ps/packfile-store-in-odb-source. I
> decided to not make this a dependency though because those two topics
> are independent from one another, and I expect that this series here
> will be merged down faster than the conflicting one. Furthermore, the
> conflict itself is quite minor:
>
> diff --cc packfile.c
> index 8daa5a5ee7,ce6716fbea..0000000000
> --- a/packfile.c
> +++ b/packfile.c
> @@@ -2157,10 -2132,11 +2151,10 @@@ int packfile_store_read_object_info(str
>   				    struct object_info *oi,
>   				    unsigned flags UNUSED)
>   {
>  -	static struct object_info blank_oi = OBJECT_INFO_INIT;
>   	struct pack_entry e;
>  -	int rtype;
>  +	int ret;
>   
> - 	if (!find_pack_entry(store->odb->repo, oid, &e))
> + 	if (!find_pack_entry(store, oid, &e))
>   		return 1;
>   
>   	/*
> @@@ -2549,9 -2555,8 +2571,9 @@@ int packfile_store_read_object_stream(s
>   	oi.sizep = &size;
>   
>   	if (packfile_store_read_object_info(store, oid, &oi, 0) ||
>  -	    oi.u.packed.is_delta ||
>  +	    oi.u.packed.type == PACKED_OBJECT_TYPE_REF_DELTA ||
>  +	    oi.u.packed.type == PACKED_OBJECT_TYPE_OFS_DELTA ||
> - 	    repo_settings_get_big_file_threshold(store->odb->repo) >= size)
> + 	    repo_settings_get_big_file_threshold(store->source->odb->repo) >= size)
>   		return -1;
>   
>   	in_pack_type = unpack_object_header(oi.u.packed.pack,
>
> I'd thus propose to merge this series via an evil merge, but if this
> proves to be burdensome I'm happy to defer it to a later point. Just let
> me know and I'll adapt accordingly, thanks!

Indeed the conflicts above are miniscule that it does not even need
any evil merge.  The surviving lines are all from either ours or
theirs, that changes are close enough to be shown in --cc.

But let me first concentrate more on fixing performance regression
that already made down to 'master'.  It is a shame that nobody
caught it while it was cooking in 'next'.

Thanks.