Sorry for the delay, I've been away.

master table: I think the final row's results are wrong: the code will set both the foreground and the background regardless of g:gitgutter_set_sign_backgrounds.

pr 729 table: as far as I can tell your PR doesn't use the g:gitgutter_set_sign_backgrounds variable, so I don't understand where the results in the "set_sign_bg 1" column come from. I would think the behaviour is always as per the "set_sign_bg 0" column.

In master, there are two scenarios where set_sign_bg is 0 and the background still gets set by the plugin.

You are right and when you put it like this, it sounds confusing ;) Two assumptions I never wrote down were:

• if someone has bothered to define GitGutter* highlight groups, they will have set the foreground colours;
• g:gitgutter_set_sign_backgrounds only applies to existing GitGutter* highlight groups.

Is this plugin trying to do too much for the user?
...if the user is setting colors themselves, then they can just take care of it on their own?

I think this is subjective. It certainly isn't necessary for the plugin to adjust the signs' background colours automatically and it makes the code more complicated. However, when changing colorschemes, I think it is helpful for the plugin to adjust the signs' backgrounds automatically to match the new sign column colour (admittedly only necessary if the user has defined GitGutter* highlight groups, not the colourscheme).

Having said all that, your final table looks ideal to me and I think we should make the plugin do that.