Improve code authorship attribution

[myteo]

Currently in the code panel, an author is credited for lines of code that was last modified them. However, another author might have written the line initially and the current author (author who last modified the line) might have only made a slight modification to the line. In such a case, the current author gets credited for work that is not entirely done by them.

Proposed solution:
Assign partial or full credit of a line to the current author based on whether they introduced the line or someone else introduced the line and they only made a slight modification to it. This is done by checking the ancestor line (previous version of the line) to see how similar it is to the line. Users add a command line flag to indicate if they want this feature to be turned on - it is turned off by default.

For a given line l and author a who last modified the line, we can assign credit to author a using the following steps:

1. Check the commit in which author a modified line l
2. Get the diffs of the commit and find the hunk which line l belongs to
3. Go through all the deleted lines in the hunk and compare them with line l to see how similar they are (using Levenshtein string distance metric)
4. If we do not find a deleted line with high similarity with line l, we give author a full credit. If we find such a deleted line, we find out the author of the deleted line.
5. If the author of the deleted line is not author a, we give partial credit to author a. If the author of the deleted line is author a, we set line l as the deleted line and repeat from step 1.

After we assign partial or full credit to the author, we can display the results in the code panel by using a darker shade of green to highlight code with full credit.

[myteo]

Some additional implementation details:

1. We can get the author who last modified a line using git blame
2. We can get the diffs of a commit using git diff
3. In the case of a merge commit, we need to get the diff w.r.t each parent of the commit
4. How to calculate the similarity of line l2 w.r.t line l1:

• Get the Levenshtein string distance d between line l1 and line l2 (brief explanation of Levenshtein distance here)
• The similarity score will be 1 - (d ÷ length of line l1). It will be a score between 0 and 1.
• We need to set a threshold similarity value. Based on some testing, I propose using a value of 80% similarity for now.
• Out of all the deleted lines that meet the threshold value, we choose the one with the highest score

5. We should ignore empty lines

[eugenepeh]

So in this algorithm, given the flow:

1. A authored a new line
2. B modified the line (minor edit)
3. A modified the line (minor edit)

The full credit in this case will go to A or B?

[myteo]

For this case, A will be given partial credit.

After this change, the author who last modified the line will still get credit as before, but this algorithm will determine if he/she gets partial or full credit. That means for the line described above, B will still not receive any credit.

When tracing the "ancestry" of a line, the algorithm terminates and gives partial credit once a different author is found. So for the line described, once we find out that B authored the previous version, we will give A partial credit and analysis will stop there. This is less rigorous, but saves the time of having to trace the ancestry of the line all the way back to the start.

Hope this clarifies, do let me know if you think there are areas which could be improved. Thanks!

[jinyao-lee]

Just to ask and clarify:

• Given authors a and b and a line l:

  • If a initially authored l, and b made a major modification to that line (i.e.: similarity score < 0.8), b gets the full credit?
  • If a initially authored l, and b only makes a minor modification to that line (i.e.: similarity score > 0.8), b gets the partial credit?

• The intended solution will still be crediting to the author who last modified that line, with the addition of giving that author full/partial credit (based on the different shades of green color) based on the calculated min edit distance?

[myteo]

Thanks for clarifying! To answer your questions:

• If a initially authored l, and b made a major modification to that line (i.e.: similarity score < 0.8), b gets the full credit?

Yup correct.

• If a initially authored l, and b only makes a minor modification to that line (i.e.: similarity score > 0.8), b gets the partial credit?

Yup correct, strictly speaking >= 0.8.

• The intended solution will still be crediting to the author who last modified that line, with the addition of giving that author full/partial credit (based on the different shades of green color) based on the calculated min edit distance?

Yup correct.

[eugenepeh]

One more question, how far do we go in terms of tracing the ancestry of a line?

[myteo]

One more question, how far do we go in terms of tracing the ancestry of a line?

Currently there is no limit to how far back we trace the ancestry. The current way it works is that the tracing will stop if:

1. Ancestor line has similarity value < 80% [give full credit]
2. Ancestor line has similarity value >= 80% and author of ancestor line is someone else [give partial credit]

We continue to trace if the ancestor line has similarity value >= 80% and is written by the author (author who last modified the line). In the worst case, the tracing will stop when there are no ancestor lines. Ie. the commit where the file was first added.

[eugenepeh]

We continue to trace if the ancestor line has similarity value >= 80% and is written by the author (author who last modified the line). In the worst case, the tracing will stop when there are no ancestor lines. Ie. the commit where the file was first added.

Would it be faster if we just find the original author and the last modifier of the line?

[myteo]

If we just find the original author, we would still need to trace the ancestry of the line but we save the time needed to check the author of each of the ancestor lines during tracing. On the other hand, the current method checks the author of each of the ancestor lines but is able to terminate early once a different author is found.

The author of a line is obtained from the results of the git blame command, which is needed anyway to find the commit in which the ancestor line was modified, so the time saved would mainly come from extracting the author from the git blame results. Thus I think the current method might still be faster since the time saved from checking the author might not outweigh the time saved from terminating early.

[SkyBlaise99]

Hi @dcshzj, I would like to continue working on this issue. Anything I need to take note of? I observed that #949 left by @myteo is near complete, what are the issues preventing it from being merged apart from merge conflicts?

[damithc]

@SkyBlaise99 it's been a while since someone looked at this PR. Perhaps you can send a cleaned up PR and we can get the current active developers to take a fresh look?

[SkyBlaise99]

Sure prof @damithc, I'm planning to make a new pr since the old one has too much merge conflict to resolve.