git/add-interactive.c, branch v2.36.2

Merge branch 'pw/single-key-interactive'

2022-03-21T22:14:24Z

The single-key interactive operation used by "git add -p" has been made more robust. * pw/single-key-interactive: add -p: disable stdin buffering when interactive.singlekey is set terminal: set VMIN and VTIME in non-canonical mode terminal: pop signal handler when terminal is restored terminal: always reset terminal when reading without echo

add -p: disable stdin buffering when interactive.singlekey is set

2022-02-23T21:30:06Z

The builtin "add -p" reads the key "F2" as three separate keys "^[", "O" and "Q". The "Q" causes it to quit which is probably not what the user was expecting. This is because it uses poll() to check for pending input when reading escape sequences but reads the input with getchar() which is buffered by default and so hoovers up all the pending input leading poll() think there isn't anything pending. Fix this by calling setbuf() to disable input buffering if interactive.singlekey is set. Looking at the comment above mingw_getchar() in terminal.c I wonder if that function is papering over this bug and could be removed. Unfortunately I don't have access to windows to test that. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

diff.[ch]: have diff_free() call clear_pathspec(opts.pathspec)

2022-02-16T21:50:13Z

Have the diff_free() function call clear_pathspec(). Since the diff_flush() function calls this all its callers can be simplified to rely on it instead. When I added the diff_free() function in e900d494dcf (diff: add an API for deferred freeing, 2021-02-11) I simply missed this, or wasn't interested in it. Let's consolidate this now. This means that any future callers (and I've got revision.c in mind) that embed a "struct diff_options" can simply call diff_free() instead of needing know that it has an embedded pathspec. This does fix a bunch of leaks, but I can't mark any test here as passing under the SANITIZE=leak testing mode because in 886e1084d78 (builtin/: add UNLEAKs, 2017-10-01) an UNLEAK(rev) was added, which plasters over the memory leak. E.g. "t4011-diff-symlink.sh" would report fewer leaks with this fix, but because of the UNLEAK() reports none. I'll eventually loop around to removing that UNLEAK(rev) annotation as I'll fix deeper issues with the revisions API leaking. This is one small step on the way there, a new freeing function in revisions.c will want to call this diff_free(). Signed-off-by: Ævar Arnfjörð Bjarmason Reviewed-by: Elijah Newren Signed-off-by: Junio C Hamano

.h: move some _INIT to designated initializers

2021-09-27T21:48:00Z

Move various *_INIT macros to use designated initializers. This helps readability. I've only picked those leftover macros that were not touched by another in-flight series of mine which changed others, but also how initialization was done. In the case of SUBMODULE_ALTERNATE_SETUP_INIT I've left an explicit initialization of "error_mode", even though SUBMODULE_ALTERNATE_ERROR_IGNORE itself is defined as "0". Let's not peek under the hood and assume that enum fields we know the value of will stay at "0". The change to "TESTSUITE_INIT" in "t/helper/test-run-command.c" was part of an earlier on-list version[1] of c90be786da9 (test-tool run-command: fix flip-flop init pattern, 2021-09-11). 1. https://lore.kernel.org/git/patch-1.1-0aa4523ab6e-20210909T130849Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'rs/xcalloc-takes-nelem-first'

2021-03-19T22:25:39Z

Code cleanup. * rs/xcalloc-takes-nelem-first: fix xcalloc() argument order

use CALLOC_ARRAY

2021-03-14T00:00:09Z

Add and apply a semantic patch for converting code that open-codes CALLOC_ARRAY to use it instead. It shortens the code and infers the element size automatically. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

fix xcalloc() argument order

2021-03-08T17:45:04Z

Pass the number of elements first and ther size second, as expected by xcalloc(). Provide a semantic patch, which was actually used to generate the rest of this patch. The semantic patch would generate flip-flop diffs if both arguments are sizeofs. We don't have such a case, and it's hard to imagine the usefulness of such an allocation. If it ever occurs then we could deal with it by duplicating the rule in the semantic patch to make it cancel itself out, or we could change the code to use CALLOC_ARRAY. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'js/add-i-color-fix'

2020-12-08T23:11:17Z

"git add -i" failed to honor custom colors configured to show patches, which has been corrected. * js/add-i-color-fix: add -i: verify in the tests that colors can be overridden add -p: prefer color.diff.context over color.diff.plain add -i (Perl version): color header to match the C version add -i (built-in): use the same indentation as the Perl version add -p (built-in): do not color the progress indicator separately add -i (built-in): use correct names to load color.diff.* config add -i (built-in): prevent the `reset` "color" from being configured add -i: use `reset_color` consistently add -p (built-in): imitate `xdl_format_hunk_hdr()` generating hunk headers add -i (built-in): send error messages to stderr add -i (built-in): do show an error message for incorrect inputs

add -p: prefer color.diff.context over color.diff.plain

2020-11-16T23:59:02Z

Git's diff machinery allows users to override the colors to use in diffs, even the plain-colored context lines. As of 8dbf3eb6850 (diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT, 2015-05-27), the preferred name of the config setting is `color.diff.context`, although Git still allows `color.diff.plain`. In the context of `git add -p`, this logic is a bit hard to replicate: `git_diff_basic_config()` reads all config values sequentially and if it sees _any_ `color.diff.context` or `color.diff.plain`, it accepts the new color. The Perl version of `git add -p` needs to go through `git config --get-color`, though, which allows only one key to be specified. The same goes for the built-in version of `git add -p`, which has to go through `repo_config_get_value()`. The best we can do here is to look for `.context` and if none is found, fall back to looking for `.plain`, and if still not found, fall back to the hard-coded default (which in this case is simply the empty string, as context lines are typically rendered without colored). This still leads to inconsistencies when both config names are used: the initial diff will be colored by the diff machinery. Once edited by a user, a hunk has to be re-colored by `git add -p`, though, which would then use the other setting to color the context lines. In practice, this is not _all_ that bad. The `git config` manual says this in the `color.diff.`: `context` (context text - `plain` is a historical synonym) We should therefore assume that users use either one or the other, but not both names. Besides, it is relatively uncommon to look at a hunk after editing it because it is immediately staged by default. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

add -i (built-in): use the same indentation as the Perl version