Junio C Hamano <gitster@xxxxxxxxx> writes: >>> The person who moved the code will be on the list regardless, >> >> That is exactly the point I have been trying to raise. Does the >> person appear in the list when you run blame with -CCC? You ask for > > s/person/commit/; > >> the body of the function, and the -C mode of blame sees through the >> block-of-line movement across file boundaries, and goes straight to >> the last commit that touched the body of the function in its original >> file, no? -- >8 -- cd /var/tmp/ git init blame cd blame cp /src/git/COPYING COPYING git add COPYING git commit -m initial sed -ne 120,140p COPYING >EXTRACTING git add EXTRACTING git commit -m second git blame -C -C -C EXTRACTING -- 8< -- will show that all lines from EXTRACTING came from the original revision of COPYING, and we will miss the line-move event. "blame -C" with a single -C does not look at the files that did not change in the commit that added these lines to EXTRACTING (i.e. COPYING), so the digging stops there. After this, if you do this: -- >8 -- echo >>COPYING git commit --amend -a --no-edit git blame -C EXTRACTING -- 8< -- then the commit that did add these lines to EXTRACTING touched COPYING, and the origin of these lines are traced to it (this is designed to be useful in a typical "refactor by moving code"; "cut and paste without changing the original" people need heavier copy detection with more -C). IIRC, git-gui runs two blames, one without any -C and one with (I do not offhand recall how many -C it uses) to show both. HTH. -- 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