From: Junio C Hamano Date: Mon, 23 Oct 2017 02:04:49 GMT Subject: Re: Ascertaining amount of "original" code across files/repo Message-ID: In-Reply-To: <20171022212505.wxdpfaevxw7fsn7e@laptop.local> Thomas Adam writes: > What I did was first of all ascertain the number of original lines in each of > the files I was interested in: > > for i in *.[ch] > do > c="$(git --no-pager blame "$i" | grep -c '^\^')" > [ $c -gt 0 ] && echo "$i:$c" > done | sort -t':' -k2 -nr Another approach I've used when I was curious how many among 1244 lines Linus originally wrote for Git in 2005 remains in today's codebase goes the other way [*1*]. The "reverse" approach makes use of the -S option of blame to fabricate a hypothetical history where the very initial version of Git is today's version, and then there is another version that was built on it (eh, rather reduced out of it) which is Linus's original. $ git tag initial e83c5163316f89 $ cat >fake-history < e83c5163316 5) #include e83c5163316 6) #include e83c5163316 7) #include The idea is that a line that is blamed to the "root" commit (i.e. blank prefix) is what survived since Linus's version down to our current version. In the fake world, Linus started from our today's version and ended up with the same result in his version for these lines. A line that is blamed to e83c516 is something we do not have in our today's version that is "added" by Linus in this fake world---that in reality is what we "lost" from Linus's original over time. By adding -M and -C on "git blame" command line, you'll find more lines that survived over time from Linus's original by getting moved around inside the same file and across file boundaries. By adding -w, indentation-only changes would also be ignored. I am not judging which is more correct to go in the forward direction like your approach does or to go in the reverse, as I haven't thought about it deeply enough. [Reference] *1* https://docs.google.com/file/d/0Bw3FApcOlPDhMFR3UldGSHFGcjQ/view Slide #11 was created using the above method.