-
Notifications
You must be signed in to change notification settings - Fork 380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve blame file type detection (#1803) #1829
Improve blame file type detection (#1803) #1829
Conversation
src/utils/process.rs
Outdated
|
||
let args = make_string_vec(&["git", "blame", "-w", "-C", "main.rs"]); | ||
assert_eq!(guess_git_blame_filename(&args), Args("main.rs".into())); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That unfortunately doesn't really fix it: Now -w
takes an argument (when it does not), which means it "eats" the following -C
. The problem is -C[<num>]
, which only takes a non-whitespace argument (or none) -- but this not really modeled at the moment.
Removing -C
from the previous list should work for most cases. In the future a fallback to take the last argument containing a .
should be added. And make it use the CallingProcess
enum as mentioned in the TODO there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been tricked by only looking at the synopsis part of the git blame man page when adding -w
to this list.
I'll look at addressing this TODO and making a variant in CallingProcess
.
5392bc4
to
c5bc7ed
Compare
Signed-off-by: dvermd <315743+dvermd@users.noreply.github.com>
c5bc7ed
to
aa78604
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, a few small things.
Signed-off-by: dvermd <315743+dvermd@users.noreply.github.com>
Looks good, thank you! |
closes #1803