I did this for a school project, because students would "cheat" on group projects by exclusively changing whitespace in diffs, or moving code around, thereby making it look like they had large commits.
We tracked code "moves", whitespace changes, and "trivial" changes via Levenshtein distance--which isn't great for capturing most simple renamings--and then marked them up separately in an "augmented diff".
We briefly looked into doing AST edit-distance, but that turned out to be infeasible for many reasons.
Over-all it helped the prof grade faster, at least in the degenerate cases.
Measuring a student's impact by a project on the number of lines of code they committed can be very misleading.
Sure, in the extremes it will give sensible results (someone wrote only 3 lines, or wrote 90% of the code base).
But minor, questionably motivated refactorings can create huge commits, while someone may come up with some great design while walking around for hours and sketching on paper, which all ultimately boils down to a short function.
Dumb metrics like this cannot replace actually talking with the students, asking questions about their choices and alternatives, having them do presentations or lab notebooks/logbooks etc.
> Dumb metrics like this cannot replace actually talking with the students, asking questions about their choices and alternatives, having them do presentations or lab notebooks/logbooks etc.
As said in the parent:
>> Over-all it helped the prof grade faster, at least in the degenerate cases.
We tracked code "moves", whitespace changes, and "trivial" changes via Levenshtein distance--which isn't great for capturing most simple renamings--and then marked them up separately in an "augmented diff".
We briefly looked into doing AST edit-distance, but that turned out to be infeasible for many reasons.
Over-all it helped the prof grade faster, at least in the degenerate cases.