Shows uncommitted changes after blame calculation as the one calculated by the blame command

[sergiobonfiglio]

Currently, when you modify a file, changes are shown like this:

which seems inconsistent because:

1. The caret is positioned under the blame info (breaking the indentation)
2. If you were to recalculate the blame info those lines would show as "Not Committed Yet" (or just "Yet" depending on the configuration =) )

This PR shows added lines as if the blame was recalculated.

[JamiLu]

Thank you for the PR. 🚀 I have been working on this problem during this week as well.

[JamiLu]

Thank you again for the code improvements. It is always great to see people like the extension and like to contribute. But however this actually does not fix the so called indent issue. That is because there is a bug in the VS Code that when the file is opened first time or the tab is selected first time the onDidChangeTextDocument does not fire correctly with the correct data and that's why the decorations are not rendered correctly. The previous solution works as well it would just make the new lines to be empty lines.

Here is a screenshot from my testing the PR.

This screenshot shows how your code changes looks with my configuration when the event is fired correctly by the VS Code.

I also a piece of your code that retrieves the closest to the date color. It was amazing. But I am not sure will I have this in or just keep the new lines empty with the text editor background color as the current implementation. Maybe this could be an opt in setting that the can change as per wish.

But I will continue to work on this issue and try to have some workaround for the indent issue.

[sergiobonfiglio]

That's OK. For me, I was always getting the caret moved where it shouldn't be while adding new lines but the other solution wasn't perfect either (sometimes copilot's auto-completion were getting in the way). As for the empty lines or 'not committed yet', personally, I'm fine with both but I don't like the inconsistency: if you decide to go with empty lines, I would suggest to also show as empty the ones coming from git blame with a zero hash, but that's just me!

Regarding the bug you mentioned: maybe a workaround could be using git blame --incremental. With that, the newest 0 hash lines are always returned first and you can process the output as it comes out without waiting for the whole file to be processed.

[JamiLu]

Good thoughts. You could clean this PR if you’d like, and then I’ll see what I eventually use. 👍

[sergiobonfiglio]

Good thoughts. You could clean this PR if you’d like, and then I’ll see what I eventually use. 👍

What do you mean by clean?

[JamiLu]

What I actually mean is that this PR actually does not pass the build that should be fixed. :)