On Tue, Nov 10, 2020 at 05:06:59PM +0100, Johannes Schindelin wrote: > > but that is missing another thing: for historical reasons we allow both > > color.diff.frag and diff.color.frag. TBH, I wouldn't be too sad to see > > us drop support for the historical versions in this setting. But it > > makes me wonder if we could be reusing the parsing from > > git_diff_basic_config(), which handles both cases. > > Hmm. The Perl version uses the Git.pm's `get_color()` function, which in > turn invokes `git config --get-color` with the exact keys I pasted above. > > All along the way to `builtin/config.c`'s `git_get_color_config()`, I fail > to see any `color.diff`/`diff.color` munging. So I believe that `git add > --interactive` _never_ looked at the `diff.color` section to begin with. Yeah, I think you're right. And I'm not too surprised. The same "I wouldn't be too sad" probably applied back then, too. Yep: https://lore.kernel.org/git/20071122122540.GH12913@xxxxxxxxxxxxxxxxxxxxx/ > > I'm not entirely clear on how add-interactive.c invokes the diff, and > > whether it would be unhappy to pick up diff config. But it seems like > > this: > [...] > > Hmm. I don't like it. So far, we were very careful to keep respecting > `struct repository *r` in the built-in interactive add command. This would > go the exact opposite way. > > Combined with the fact that we never supported `diff.color.*` in the > interactive add command anyway, I would rather continue with the first > variant you presented. Yeah, that seems quite sensible to me. -Peff
