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.


  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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to