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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html