Junio C Hamano <gitster@xxxxxxxxx> writes:
> When looking at a merge, "git blame" inspects the blob object names
> of all parents and if one of them exactly match the merge result,
> pass the entire blame down to that parent. This is very much in
> line with the history simplification done with "git log" when
> traversing a history with merges.
[...]
> Now, imagine if you amend M to create N, to add a single line at the
> end of path. M:path != N:path but there is very small difference
> between the two. That means B:path != N:path but the difference
> between this merged result and the second parent is very small.
That sounds very much like
commit d5df1593f27bfceab807242a538cb3fa01256efd
Merge: 7144168 0b4e246
Author: Junio C Hamano <gitster@xxxxxxxxx>
Date: Fri Feb 28 13:51:19 2014 -0800
Merge branch 'bl/blame-full-history' into pu
By disabling the tree-same optimization (which is consistent with
the default behaviour of "git log"-family of commands), make "git
blame" sometimes produce different result from the original code.
Because the "git blame" output can give result for each line from
only one lineage of the history, however, this can be only useful
when you are lucky---unlike "--full-history" of "git log"-family,
where we can show commits from both lineages of histories with an
equal weight. See $gmane/240392 for more detailed discussion.
* bl/blame-full-history:
blame: new option --prefer-first to better handle merged cherry-picks
--
David Kastrup
--
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