Codecov Report

Attention: Patch coverage is 94.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 88.29%. Comparing base (6b9e124) to head (9725953).
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master     #361      +/-   ##
==========================================
+ Coverage   88.28%   88.29%   +0.01%     
==========================================
  Files          66       66              
  Lines        6613     6647      +34     
==========================================
+ Hits         5838     5869      +31     
- Misses        775      778       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hi! Interesting.

I remember writing this code and realizing that parsing it becomes ambiguous. File paths may contain forward slashes, and files may contain spaces.

I'm thinking the least we could do is to make it a little more robust. Perhaps check for [a-z]/.

Sometimes the files are not present down in the

--- i/file1.txt
+++ w/file2.txt

I've pushed a test to demonstrate this to master. What do you think?

Hey! Just pulled from master and saw the test was failing. Fixed it in the latest commit though, and now everything's passing.

The code now handles those prefixes like "i/" and "w/" you mentioned, plus the unified diff format with the "---" and "+++" stuff.

Anything else you think we should fix while I'm at it?

PS.
I'm curious though - any particular reason why you decided to roll your own parser instead of using libgit2 bindings? Wouldn't that handle all these edge cases automatically and give you access to Git's internal data structures directly?

Thanks for this really nice tool btw!

Without having looked at the source-code, I wonder how git itself handles parsing edge-cases like this.

I think that this way should cover 99.9% of cases at least. (unless someone puts their file inside of a i/ directory...

Perhaps using the regex crate would simplify the implementation? (it's already a dependency)

PS.
I'm curious though - any particular reason why you decided to roll your own parser instead of using libgit2 bindings? Wouldn't that handle all these edge cases automatically and give you access to Git's internal data structures directly?

Gitu used to use libgit2 to parse diffs, but I found the output quite hard to work with.
Especially when it came to working with generating patches / highlighting the text.
I wanted indices into the text, but I couldn't find any lib that did this.
My thought was, fixing these kinds of problems is easier, and will be worth it.
We'll see if that still holds true after some time x)

Without having looked at the source-code, I wonder how git itself handles parsing edge-cases like this.

I think that this way should cover 99.9% of cases at least. (unless someone puts their file inside of a i/ directory...

Perhaps using the regex crate would simplify the implementation? (it's already a dependency)

PS.
I'm curious though - any particular reason why you decided to roll your own parser instead of using libgit2 bindings? Wouldn't that handle all these edge cases automatically and give you access to Git's internal data structures directly?

Gitu used to use libgit2 to parse diffs, but I found the output quite hard to work with. Especially when it came to working with generating patches / highlighting the text. I wanted indices into the text, but I couldn't find any lib that did this. My thought was, fixing these kinds of problems is easier, and will be worth it. We'll see if that still holds true after some time x)

Done using regex crate.