fix: git diff filename parsing when filenames contain spaces - #547
Open
Treeniks wants to merge 1 commit into
Open
fix: git diff filename parsing when filenames contain spaces#547Treeniks wants to merge 1 commit into
Treeniks wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Checklist
make testis passing (this is what CI runs).feat:/fix:/style:/perf:. Or e.g.perf(highlighting):.See https://github.com/altsem/gitu/blob/master/docs/dev-tooling.md
fixes #499
It seems git adds a tab character behind filenames with spaces in them to clearly differentiate what is still part of the filename, and what is the delimiter for metadata (even when not printing any metadata). Not an issue when the filenames get quoted, but as far as I can tell, they don't by default. This resulted in the
git addcommand including that tab character, which caused an error.I simply added a new
newline_or_tab_or_eofdelimiter that is now used instead. I haven't looked into the testing setup, so I didn't write any tests for this.During debugging, I also noticed that the
fmt::Debugimplementation on the Parser often fails on thelog::trace!call insidenewline_or_eof. I think it's becauseline_endis a byte index for the string sliceself.input[line_start..], not for the entire string. So one would probably need something like:However, it still panicked because
cursorsometimes didn't land on a proper unicode byte. I guess there is more wrong here, so I left it out of this PR.