On Thu, May 23, 2013 at 6:47 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >>> If the change in HEAD^ in the above example were to copy the whole A >>> and C from a different file, then your !found_guilty logic would >>> kick in and say all lines of A where copied from elsewhere in HEAD^, >>> but again we would not learn the same information for C. >> >> We would, when it's the turn for C, which is not guilty at this point. > > In _this_ round of the while(1) loop, pass_blame_to_parent() gets > the scoreboard and two origins (HEAD^ that we are looking at and > HEAD^^ that is its parent); it does not even know what blame entry > this request came from. > > It runs a single diff using diff_hunks(), and asks blame_chunk() to > split all the blame entries in the scoreboard that suspect it is > looking at may be guilty for. Blame entry for A and C are both > processed exactly the same way when HEAD^ is given to pass_blame() > for the first time, which is when assign_blame() decided to call it > with HEAD^ because it happened to have seen A before seeing C. At > that point, both A and C are processed, and the post-processing loop > "Take responsibility for the remaining" will clean up remnants from > both A and C. After this round ends, the suspect for A and C are > both set to HEAD^^. > > In the next round of the while(1) loop, C already forgot that its > line movement happened in HEAD^. Its suspect is now HEAD^^. When > "it's the turn for C" [*1*], you can say "These lines originate in > that different path in HEAD^^", but it is too late to say "But the > first time they appeared in the original file was HEAD^" (which is > when they were moved from the different path in HEAD^^), isn't it? If that's the case then we'll need another list of blame entries where each discarded blame entry goes. Given the luck of my previous obvious patches, I'm not interested in implementing this non-obvious one in the least. The point is 'git related' should do -C -C -C, if 'git blame' doesn't throw the right output, that's a bug in 'git blame' not 'git related. -- Felipe Contreras -- 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