Do Not Track Changes After git Rebase

[reidspreiter]

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 of git after rebasing.

To achieve the following results, two commits were made, then reordered:

[Cargo.toml]  <<< Text Document Change Event >>>
[Cargo.toml]    scheme: file
[Cargo.toml]    git: false
[Cargo.toml]    changes: 1
[Cargo.toml]  
[Cargo.toml]    change 1 {
[Cargo.toml]      range: 7:14 -> 13:99
[Cargo.toml]      deleted: 312
[Cargo.toml]      added: 302 (
[Cargo.toml]        
[Cargo.toml]        phf = { version = "0.11.2", features = ["macros"] jkhjkghjhkjh
[Cargo.toml]        bimap = "0.6.3"
[Cargo.toml]        actix-web = "jkhjkghjhkjh
[Cargo.toml]        actix-files = "0.6.jkhjkghjhkjh
[Cargo.toml]        serde = { version = "1.0", features = ["derive"]jkhjkghjhkjh
[Cargo.toml]        sshfhshdfhsdfhsihfsidsdifhsdfhsdufisdfiuhdfdfgdfgddfgdfgdfgdfgdfgdfgdfgdfgdfgjkjkjkbkjkhjkghjhkjh
[Cargo.toml]      )
[Cargo.toml]    }
[Cargo.toml]  
[Cargo.toml]    ACCEPTED
[Cargo.toml]  <<< End Event >>>

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.

[reidspreiter]

Coverage of other rebase operations:

• reword: no issues
• squash: no issues
• fixup: no issues
• pick: no issues
• drop: really bad. no indication of git operations. Pastes changes after drop in a single event.
• reorder: contrary to this issue, there are no issues if there are no merge conflicts
• edit: no issues if commits are staged and amended. Works with merge conflicts too
• merge conflict: if git operations are being performed, no issues. But if any manual characters are pressed while resolving merge conflicts, git operations are exited and commits thereafter are picked up. To resolve this we should add a regex to match the merge conflict text to reenable git operations / put in merge conflict mode. If in merge conflict mode, a schema of git must be found to take out of merge conflict mode

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.

[reidspreiter]

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.