Can't use string ("auto") as a HASH ref while "strict refs" in use at /usr/local/bin/diff-so-fancy line 376.

[SimenB]

When I try to use the colors you've defined in your readme, I get the title as an error.

This is using 1.1.0.

[color "diff-highlight"] are ok, but not [color "diff"].

Full git config https://github.com/SimenB/vcsh_git/blob/2f94f33d90261c4690c557bbecc9901d1b00edb3/.gitconfig

[SimenB]

Ok, figured it out. It was because I had [color] diff = auto. Not sure if it should be considered a bug? Maybe print a better message.

https://github.com/SimenB/vcsh_git/blob/2f94f33d90261c4690c557bbecc9901d1b00edb3/.gitconfig#L35

As an aside, I don't think the colors you suggest in the readme are better than auto.

Auto:

Colors in readme:

EDIT: One thing better with your colors are the new rename highlight.

Auto:

Colors in readme:

I still like the diff colors you get from auto more, though. Might be just my color scheme?

[scottchiefbaker]

I didn't even know color "auto" was a thing. I'll take a look at this and let you know when I find the fix.

[OJFord]

FWIW, it's the default, (rename your git/config and run git config --list) so should probably be fixed.

Regarding colour preference though, I believe (though I can't find a reference) that auto uses some default assignments of red, green, whatever; which in turn use the colours for those ANSI codes as defined in your terminal configuration. In general, that probably is what you want; if you want to go blue/yellow rather than red/green for example, using blue, yellow instead of specific codes will ensure it picks up your terminal colour scheme, leaving you with just a single place to ensure the colours are legible in their various combinations, and on your background.

I think the colours suggested in the readme are more an 'FYI, these are what were used for the screenshots'.

[SimenB]

The default colors are not the best so we recommend the following color settings as a base.

Maybe it could also suggest to try "auto"?

Is it possible to get rename highlight to work with auto?

[scottchiefbaker]

rename hightlight is handled by DiffHighlight so it uses the d-h colors:

[color "diff-highlight"]
    oldNormal = red bold
    oldHighlight = red bold 52
    newNormal = green bold
    newHighlight = green bold 22

[scottchiefbaker]

For what it's worth your colors/terminal seems off compared to mine. What terminal are you using?

Konsole on Linux:

[scottchiefbaker]

Circling back... I set the color to auto like you specified and I do not get the error you specified.

[color]
    branch = auto
    diff = auto
    status = auto
    ui = auto

Perhaps there is something else in your config that's triggering this? I'd like to recreate it so I can attempt to work around it.

[Leglaw]

I'm able to reproduce with this minimal config:

[color]
	diff = auto
[color "diff"]
	meta = 227
[pager]
	diff = diff-so-fancy | less --tabs=4 -RFX
	show = diff-so-fancy | less --tabs=4 -RFX

If [color "diff"] appears before [color] it doesn't produce the issue. Also, it doesn't matter what rule appears in [color "diff"], just that any rule is specified.

[scottchiefbaker]

Interesting... it definitely has to do with the order of the config. I switched the git config parsing to work around this. You can try the next repo to see if this fixes it for you.

[SimenB]

iTerm2 on mac with DimmedMonokai theme.

(tried to find the same commit, seems like I missed :P)

[scottchiefbaker]

That looks closer for sure. I'm guessing it's your theme that's skewing the colors a little bit. Not a big deal, I was just curious why they weren't mapping 1:1.

[scottchiefbaker]

@Leglaw and @SimenB This should be fixed on the beta version I released yesterday. Can you test and confirm for me?

[Leglaw]

👍 Works for me

[lancespeelmon]

FYI - same problem here... changing the order in ~/.gitconfig fixed it though.

[scottchiefbaker]

I'm 99% sure this is fixed on next. If things are quite for a couple days I'll release a 1.1.1 to fix this.