Closed reidspreiter closed 3 weeks ago
Coverage of other rebase operations:
Also, many scenarios where tracking mistakes commit changes for user entered changes are very specific, and will most likely not occur unless users are intentionally making them occur. That being said, they are still important to be solved, but are not as urgent.
Nevertheless, all of these issues could be solved if coderank only accepted single characters, no mass pastes/deletions. However, i think this is a horrible idea. I copy paste simple lines so often, and I want them to be counted. I don't want to create an incentive to always type everything character by character to get accurate data.
I think that mistakenly including git events in data is far worse than not including a thousand character long block of text pasted in though. Moreover, the user might not have programmed the thousand character long block of text themselves, just moved it somewhere else, and it would not be right to count this either. If they did program it themselves, it would already be included in their coderank data.
The solution to this issue should still try as hard as possible to prevent git changes from being tracked. But in addition to this, it should only accept copy pastes of 2 lines at most. f a block of text is longer than 2 lines, it is rejected. If the line is more than 120 characters, it is rejected. For deletions, the range field of text events will be analyzed. If it is more than 2 lines, it will be rejected. If it is 2 lines, the amount of characters deleted will be limited to 240.
Wow is this confusing. I stumbled across a simple work around that will preserve mass pasting from the user and not confuse it with git and other unwanted file operations: range
All user addition actions have a range line and character difference of 0. The start and end range will always be the same no matter what is pasted. For operations automatically performed on files, the range start and end do have a difference.
This is unfortunately not the case for deletions. However, deletions with a scheme of file performed by git are preceded by an event with a scheme of git, so unwanted deletions are covered by git status.
I'm going to go with this logic instead. Reject everything I said above about confining pastes and deletions to a character and line limit.
Not collecting events when git operations are being performed works great for simple events. However, the text document event listener receives commit changes (which the user did not enter) with a scheme of
file
before receiving anything with a scheme ofgit
after rebasing.To achieve the following results, two commits were made, then reordered:
After this event, a merge conflict text blob was also accepted. No event schema of
git
was received until after the conflict was resolved.This is a huge problem, and without any scheme information beforehand indicating that non-tracked operations are about to take place, finding a workaround will take some effort.
The solution will most likely involve inferring valid and invalid mass paste/deletion events from range, deleted, and added fields. Nevertheless, any simpler solutions should be investigated.