-
-
Notifications
You must be signed in to change notification settings - Fork 153
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
--since
flag fails when git is configured with a different diff tool
#1387
Comments
--since
flag fails when git is configured with a different diff tool
Interesting one. So I do not think #1337 will fix it, mutant first has to discover the changed lines relative to the provided git reference before than using the AST diff. Else it would have to parse "way to much" AST which would be to slow. I never was happy to parse the line information out of the diff headers (mutant ignores the body), and wish I would find a more native command to display the "changed line ranges only". So I see 2 path:
I'd prefer 2) as this would be faster and more stable. But I suspect there is an easy 1) also. I'll look into it. |
I was unable to find a solution to option 1, although I'm sure you're better placed to figure it out than me. It seems that git doesn't allow disabling a custom tool via env var. What it does allow is setting a custom diff tool via env var though and this has let me fix my workflow. I have removed the diff configuration from my |
I think mutant could set the external diff tool to the internal one, untested. |
Another option could maybe be to use —name-only and maybe a diff filter and then run the AST diff. That way you wouldn’t have to parse the output of the git diff. I actually also use a different git tool ( |
I have Difftastic configured as my default
git diff
tool with this gitconfig entry:This causes
git diff REF
to output in a different format which in turn breaks the--since
flag functionality which relies on the output to be in an expected format.I was hoping
git diff
might have a flag to force the default diff tool for a single command but as far as I can tell that isn't the case.One solution for me would be to just revert to using the regular git diff output but I'd rather not do this so I'm opening an issue hoping you have a better idea. I wonder if prioritising #1337 would make this issue go away or if that would still need to start with parsing a
git diff
output?The text was updated successfully, but these errors were encountered: