Re: 1.3.0 creating bigger packs than 1.2.3

> Nicolas Pitre <nico@cam.org> writes:
> 
> >> But I suspect we have a built-in "we sort bigger to smaller, and
> >> we cut off when we switch bins" somewhere in find_delta() loop,
> >> which I do not recall touching when I did that change, so that
> >> may be interfering and preventing 0-11-AdjLite.deg from all over
> >> the place to delta against each other.
> >
> > I just cannot find something that would do that in the code.  When 
> > --no-reuse-delta is specified, the only things that will break the loop
> > in find_delta() is when try_delta() returns -1, and that happens only 
> > when changing object type or when the size difference is too big, but 
> > nothing looks at the name hash.
> 
> The list is sorted by type then hash then size (type_size_sort),
> so if you have t/Makefile that are big medium small too-small
> and then doc/Makefile that are big medium, once you see the
> too-small t/Makefile it would not consider the big doc/Makefile
> as a candidate X-<.
> 
> This _might_ improve things:
> 
> diff --git a/pack-objects.c b/pack-objects.c
> index 09f4f2c..0c6abe9 100644
> --- a/pack-objects.c
> +++ b/pack-objects.c
> @@ -1037,7 +1039,7 @@ static int try_delta(struct unpacked *cu
>  	sizediff = oldsize > size ? oldsize - size : size - oldsize;
>  
>  	if (size < 50)
> -		return -1;
> +		return 0;
>  	if (old_entry->depth >= max_depth)
>  		return 0;
>  
> @@ -1052,7 +1054,7 @@ static int try_delta(struct unpacked *cu
>  	if (cur_entry->delta)
>  		max_size = cur_entry->delta_size-1;
>  	if (sizediff >= max_size)
> -		return -1;
> +		return 0;
>  	delta_buf = diff_delta(old->data, oldsize,
>  			       cur->data, size, &delta_size, max_size);
>  	if (!delta_buf)