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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:01:27

Jeff King [off-list ref] writes:
On Mon, Jun 02, 2014 at 10:40:44PM +0200, David Kastrup wrote:
quoted
quoted
BTW, the code does git-blame to Vicent's 2834bc2 (which I also worked
on), but actually originated in 7a979d9 (Thin pack - create packfile
with missing delta base., 2006-02-19). Not that it matters, but I was
just surprised since the code you are changing did not seem familiar to
me. I guess there was just too much refactoring during the code movement
for git-blame to pass along the blame in this case.
Without -M, "too much refactoring" for git-blame may just be moving a
function to a different place in the same file.
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?

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.

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

From: Jeff King <hidden>
Date: 2016-06-15 23:01:27

On Mon, Jun 02, 2014 at 04:09:12PM -0700, Junio C Hamano wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help