Re: [PATCH] pack-objects: use free()+xcalloc() instead of xrealloc()+memset()

[Jeff King <peff@peff.net>]

On Mon, Jun 02, 2014 at 04:09:12PM -0700, Junio C Hamano wrote:

> > I tried "git blame -M -C -C -C pack-objects.c" but couldn't get anything
> > but the whole thing blamed to 2834bc2.
> 
> Are you two being a bit too unreasonable, or trying to be fanciful
> and funny and I am not getting the humor?

We are being too unreasonable.

> Here is the relevant part of what 2834bc27 (pack-objects: refactor
> the packing list, 2013-10-24) removes from builtin/pack-objects.c:
> 
> -	object_ix = xrealloc(object_ix, sizeof(int) * object_ix_hashsz);
> -	memset(object_ix, 0, sizeof(int) * object_ix_hashsz);
> 
> And here is how the same rehash is done in pack-objects.c at the
> toplevel in the new code:
> 
> +	pdata->index = xrealloc(pdata->index, sizeof(uint32_t) * pdata->index_size);
> +	memset(pdata->index, 0, sizeof(int) * pdata->index_size);
> 
> Surely, the code structure may be similar, but the similarity ends
> there.  These lines are not equivalent even under the "-w" option.

Yes, I did not expect these particular lines to get blamed, but I
thought some of the surrounding function would (which could lead to a
parent-blame to find the true origin). Skimming the diff, it looked like
some of them made it through unscathed. But they didn't.

Running:

  git show 2834bc2 |
  perl -lne '
    /^-(.*)/ and $del{$1}++;
    print "$.: $_" if /^\+(.*)/ && $del{$1};
  '

shows that there are only a handful of interesting lines that survived
completely intact, and typically not more than one line in a row.  The
big exceptions are the bits that made it into pack-objects.h, and a "git
blame" there does find the code movement.

So I think everything is operating as expected.

-Peff