]> git.ipfire.org Git - thirdparty/git.git/commit
add: check color.ui for interactive add
authorDerrick Stolee <derrickstolee@github.com>
Tue, 6 Jun 2023 14:20:18 +0000 (14:20 +0000)
committerJunio C Hamano <gitster@pobox.com>
Mon, 12 Jun 2023 17:49:16 +0000 (10:49 -0700)
commit7cf3b49f47f02ed1cab5b1cd03a5e27acaa13c99
tree9b617ce703f8147338e11edd92e47d0be1e7a552
parent0d1bd1dfb37ef25e1911777c94129fc769ffec38
add: check color.ui for interactive add

When 'git add -i' and 'git add -p' were converted to a builtin, they
introduced a color bug: the 'color.ui' config setting is ignored.

The included test demonstrates an example that is similar to the
previous test, which focuses on customizing colors. Here, we are
demonstrating that colors are not being used at all by comparing the raw
output and the color-decoded version of that output.

The fix is simple, to use git_color_default_config() as the fallback for
git_add_config(). A more robust change would instead encapsulate the
git_use_color_default global in methods that would check the config
setting if it has not been initialized yet. Some ideas are being
discussed on this front [1], but nothing has been finalized.

[1] https://lore.kernel.org/git/pull.1539.git.1685716420.gitgitgadget@gmail.com/

This test case naturally bisects down to 0527ccb1b55 (add -i: default to
the built-in implementation, 2021-11-30), but the fix makes it clear
that this would be broken even if we added the config to use the builtin
earlier than this.

Reported-by: Greg Alexander <gitgreg@galexander.org>
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/add.c
t/t3701-add-interactive.sh