Re: RFC GSoc Idea: blame: do not overly favor earlier parents

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Kastrup <dak@xxxxxxx> writes:

> 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

That one was an attempt to solve the right issue in a wrong way,
made things worse by breaking the consistency with the history
simplification of "git log".

The "Idea" is to solve it in the way that is still consistent with
the usual history simplification.


--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]