-
Notifications
You must be signed in to change notification settings - Fork 335
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
Option to use negative style for inline change highlights #374
Comments
Are you sure you haven't just blindly copied:
from the readme? 🙂 Highlighting in d-s-f is entirely delegated to |
I did look at my configs, to be sure (I set this up a while ago), but none of the settings from the README were defined there: $ git config --list | grep color
color.diff=auto
color.interactive=auto
color.status=auto
color.ui=auto
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red
color.diff.new=green
color.status.added=green
color.status.changed=yellow
color.status.untracked=cyan |
Note that I set |
That's up to the packager (for whatever package manager you used to install it) really - I think the only first-party package (other than the GitHub releases of course) is npm. But unless you're on a platform that distributes git without it, (v. rare) I don't see why they would. @scottchiefbaker I'm not lying about this, am I? --
I tried to read some perl, and briefly thought it actually was just inverting the colour instead of using diff-highlight's, but then realised - as far as I can tell - that's only in the case of the subroutine for empty lines. |
The script seems to be almost identical to git's copy. It sure looks like those differences are what's causing the discrepancy. |
Oh sorry, I didn't realise that was included. Nor do I know anything about perl to be able to say whether it needs to be, or if it can still be 'imported' and used as a package like this from the copy distributed with git. I'll let Scott answer on whether those differences can be updated, or if we can even just use upstream's directly. 🙂 |
FWIW I ended up here because the default highlighting is unreadable for my poor old eyes (looks smudged). I ended up with: [color "diff-highlight"] ...and it works great. |
Can this issue be closed then? |
I don't follow — why do you say so? The request is for a CLI option to make diff-so-fancy use the same coloring scheme as git's own diff-highlight script, and IIUC that is not yet available. That said, it seems like it may be worth first addressing the discrepancy between this repo's copy of the |
@scottchiefbaker Is Is there a reason (avoiding shelling out?) not just to use it from PATH, i.e. the one distributed with git? |
I see... I misunderstood. Are you setting any diff-hightlight colors in your git config? Or just relying on the colors that are hardcoded in diff-highlight itself? |
@OJFord we had to make some minor modifications to the library itself. Mainly to decrease startup time. Vanilla diff-highlight shells out to Also we changed some I have seen very little development on diff-highlight over the years, so I haven't really worried about making it a drop-in replacement. We just use a one-offed version for our needs. |
AFAIK, no — but just to make sure, is what I wrote above sufficient information, or are you referring to something not covered there? |
@waldyrious if that is your complete git config then you have not set any diff-highlight specific colors. The defaults for the d-s-f version of diff-highlight are probably just different (we made them to match the screenshot). If you want the default colors (or any other colors) then simply set them in your git config using something the docs. |
I know that I can tweak it manually :) what I am asking for here is a feature (a command-line flag, or a custom git config option, as I mentioned in my opening comment) that would allow anyone to easily emulate the style that comes by default with git's own |
I just reverted the |
First of all, thanks so much for considering making that the default in diff-so-fancy as well! However, I'm not really seeing the same output yet (note: I had to check out the Here's what I did to test: $ git remote add scott https://github.com/scottchiefbaker/diff-so-fancy
$ git fetch scott
$ git checkout scott/next
$ git -c 'core.pager=diff-highlight' show HEAD~
$ git show HEAD~ | diff-so-fancy
$ git show HEAD~ | ./diff-so-fancy Screenshot of the output: Let me know if I'm missing anything. |
OK try the |
I cannot recreate this... Try clearing ALL the color options from both You can view the decoded ANSI codes with something like:
In my case I see:
It bolds, and then resets before the added/removed lines. The resulting output is not bolded from what I see. |
I had already done so, and double-checked now.
Thanks, I've tried that — here's what I see:
Color-coded, for convenience: I don't know what could be interfering :( @OJFord any chance you could give it a try so we could compare? |
(With none in config)
|
Huh, intriguing. So what you see as (still, it's puzzling that |
@waldyrious I updated the Something is still setting bold but I have no idea what! |
I can confirm, I've pulled the latest changes, and now I get exactly the same output as @OJFord. |
I've been using the diff-highlight script that comes with git to improve my diffs' output, and I was looking to switch to
diff-so-fancy
for the extra improvements it does to the diff output; however, in terms of colors, I thinkdiff-highlight
's coloring strategy (of simply using the negative style of the same red/green color used for the non-highlighted parts of the line) works better than whatdiff-so-fancy
does:I like how all the highlight colors from
diff-highlight
preserve the existing foreground red/green colors, whereasdiff-so-fancy
introduces a new shade of green for the highlighted part. I suspect that's also why the lines with highlighted changes become bold/bright (to improve contrast). I'd like ifdiff-so-fancy
had an option to use the simpler strategy thatdiff-highlight
uses.Now, I realize that the current behavior may be preferable, so IMO a command-line flag, or git config option, to behave like
diff-highlight
would be perfectly acceptable ways to address this.The text was updated successfully, but these errors were encountered: