"Edited" Marking is too aggressive about gitgutter HOT 7 CLOSED

The command that is used to get the diff is git diff -U0 --no-color which in your example would produce output like

diff --git a/t b/t
index 7898192..c30627b 100644
--- a/t
+++ b/t
@@ -1 +1,12 @@
-a
+a,
+b
+b
+b
+b
+b
+b
+b
+b
+b
+b
+b

The part specifically that we look at is @@ -1 +1,12 @@

This basically means that this hunk of changes originally started at line 1 and occupied 1 line, it now starts at line 1 and occupies 12 lines. There isn't much data in that bit to determine which of those 12 lines are new/modified so it counts the whole hunk as modified.

You theoretically could probably parse the extra bit at the end of the output to determine this, but it would be complex, and this operation needs to be done with performance in mind since it is runs live as you type each character.

from gitgutter.

Awesome, thanks for the crystal-clear explanation of how it works.

Do you know if it's possible to know which line in the diff output maps to which line in the working buffer?

I can tell from looking through some diffs with -U0 the format basically puts the line number, and what comes after the comma is the count of lines added or removed, with the shorthand of omitting the comma and second number if the second number is 1 (i.e. one line removed or one line added). I don't need to explain that to you since this plugin clearly works great as-is. So this means we know for each "group" how many are added and how many are removed.

So if we can just do an O(n) scan (where n is # lines) through the rest of the output there, only looking at the very first character (remember, parsing through all this output, just to find each @@ @@ header, means this operation is already O(n) runtime) we can construct our totally correct sequence of markers (which will be not all "Modified" markers!). Only we'll be assembling an extra list of markers there. Not that such a list isn't probably being constructed now, anyway.

I think I know what I'll do during off-time at work tomorrow :D They're still stuck in the dark ages with Perforce.

from gitgutter.

Unfortunately I think this means that a deleted line could now be adjacent to a modified or inserted line, and that means the deletion top and bottom markers must now be multiplexed with the other icons. That's 4 additional icons!

It would be really cool, but considering how little of the code I can understand now after looking it over, I unfortunately cannot dig into it now.

from gitgutter.

You could avoid the icon thing by parsing the modification blocks and only adding the appropriate insert icons and treat removed lines as is. But yeah, I am currently satisfied as is, and don't really feel compelled to dig into that right now either.

from gitgutter.

Check it out, I took the sledgehammer approach to this piece of the git workflow.

from gitgutter.

@unphased are we good to close this?

from gitgutter.

Sure... plugin works fine, really.

from gitgutter.