git/add-patch.c, branch v2.40.2

read-cache API & users: make discard_index() return void

2022-11-21T03:06:15Z

The discard_index() function has not returned non-zero since 7a51ed66f65 (Make on-disk index representation separate from in-core one, 2008-01-14), but we've had various code in-tree still acting as though that might be the case. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'rs/add-p-worktree-mode-prompt-fix'

2022-09-15T23:09:46Z

Fix another UI regression in the reimplemented "add -p". * rs/add-p-worktree-mode-prompt-fix: add -p: fix worktree patch mode prompts

add -p: fix worktree patch mode prompts

2022-09-14T18:14:38Z

cee6cb7300 (built-in add -p: implement the "worktree" patch modes, 2019-12-21) added the worktree patch modes to the built-in add -p. Its commit message claims to be a port of 2f0896ec3ad4 (restore: support --patch, 2019-04-25), which did the same for the script git-add--interactive.perl. The script mentioned only the worktree in its prompt messages in worktree mode, while the built-in mentions the worktree and also the index, even though the command doesn't actually affect the index. 2c8bd8471a (checkout -p: handle new files correctly, 2020-05-27) added new prompt messages for addition that also mention the index in worktree mode in the built-in, but not in the script. Correct these prompts to state that only the worktree will be affected. Reported-by: David Plumpton Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'js/builtin-add-p-portability-fix'

2022-09-13T18:38:24Z

More fixes to "add -p" * js/builtin-add-p-portability-fix: t6132(NO_PERL): do not run the scripted `add -p` t3701: test the built-in `add -i` regardless of NO_PERL add -p: avoid ambiguous signed/unsigned comparison

add -p: ignore dirty submodules

2022-09-01T16:55:28Z

Thanks to always running `diff-index` and `diff-files` with the `--numstat` option (the latter with `--ignore-submodules=dirty`) before even generating any real diff to parse, the Perl version of `git add -p` simply ignored dirty submodules and does not even offer them up for staging. However, the built-in variant did not use that flag because it tries to run only one `diff` command, skipping the unneeded `diff-index`/`diff-files` invocation of the Perl variant and therefore only faithfully recapitulates what the Perl code does once it _does_ generate and parse the real diff. This causes a problem when running the built-in `add -p` with `diff-so-fancy` because that diff colorizer always inserts an empty line before the diff header to ensure that it produces 4 lines as expected by `git add -p` (the equivalent of the non-colorized `diff`, `index`, `---` and `+++` lines). But `git diff-files` does not produce any `index` line for dirty submodules. The underlying problem is not even the discrepancy in lines, but that `git add -p` presents diffs for dirty submodules: there is nothing that _can_ be staged for those. Let's fix that bug, and teach the built-in `add -p` to ignore dirty submodules, too. This _incidentally_ also fixes the `diff-so-fancy` problem ;-) Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

add -p: gracefully handle unparseable hunk headers in colored diffs

2022-09-01T16:55:21Z

In https://lore.kernel.org/git/ecf6f5be-22ca-299f-a8f1-bda38e5ca246@gmail.com, Phillipe Blain reported that the built-in `git add -p` command fails when asked to use [`diff-so-fancy`][diff-so-fancy] to colorize the diff. The reason is that this tool produces colored diffs with a hunk header that does not contain any parseable `@@ ... @@` line range information, and therefore we cannot detect any part in that header that comes after the line range. As proposed by Phillip Wood, let's take that for a clear indicator that we should show the hunk headers verbatim. This is what the Perl version of the interactive `add` command did, too. [diff-so-fancy]: https://github.com/so-fancy/diff-so-fancy Reported-by: Philippe Blain Helped-by: Phillip Wood Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

add -p: detect more mismatches between plain vs colored diffs

2022-09-01T16:49:45Z

When parsing the colored version of a diff, the interactive `add` command really relies on the colored version having the same number of lines as the plain (uncolored) version. That is an invariant. We already have code to verify correctly when the colored diff has less lines than the plain diff. Modulo an off-by-one bug: If the last diff line has no matching colored one, the code pretends to succeed, still. To make matters worse, when we adjusted the test in 1e4ffc765db (t3701: adjust difffilter test, 2020-01-14), we did not catch this because `add -p` fails for a _different_ reason: it does not find any colored hunk header that contains a parseable line range. If we change the test case so that the line range _can_ be parsed, the bug is exposed. Let's address all of the above by - fixing the off-by-one, - adjusting the test case to allow `add -p` to parse the line range - making the test case more stringent by verifying that the expected error message is shown Also adjust a misleading code comment about the now-fixed code. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

add -p: avoid ambiguous signed/unsigned comparison

2022-08-30T17:40:42Z

In the interactive `add` operation, users can choose to jump to specific hunks, and Git will present the hunk list in that case. To avoid showing too many lines at once, only a maximum of 21 hunks are shown, skipping the "mode change" pseudo hunk. The comparison performed to skip the "mode change" pseudo hunk (if any) compares a signed integer `i` to the unsigned value `mode_change` (which can be 0 or 1 because it is a 1-bit type). According to section 6.3.1.8 of the C99 standard (see e.g. https://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), what should happen is an automatic conversion of the "lesser" type to the "greater" type, but since the types differ in signedness, it is ill-defined what is the correct "usual arithmetic conversion". Which means that Visual C's behavior can (and does) differ from GCC's: When compiling Git using the latter, `add -p`'s `goto` command shows no hunks by default because it casts a negative start offset to a pretty large unsigned value, breaking the "goto hunk" test case in `t3701-add-interactive.sh`. Let's avoid that by converting the unsigned bit explicitly to a signed integer. Note: This is a long-standing bug in the Visual C build of Git, but it has never been caught because t3701 is skipped when `NO_PERL` is set, which is the case in the `vs-test` jobs of Git's CI runs. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

run-command API: rename "env_array" to "env"

2022-06-02T21:31:16Z

Start following-up on the rename mentioned in c7c4bdeccf3 (run-command API: remove "env" member, always use "env_array", 2021-11-25) of "env_array" to "env". The "env_array" name was picked in 19a583dc39e (run-command: add env_array, an optional argv_array for env, 2014-10-19) because "env" was taken. Let's not forever keep the oddity of "*_array" for this "struct strvec", but not for its "args" sibling. This commit is almost entirely made with a coccinelle rule[1]. The only manual change here is in run-command.h to rename the struct member itself and to change "env_array" to "env" in the CHILD_PROCESS_INIT initializer. The rest of this is all a result of applying [1]: * make contrib/coccinelle/run_command.cocci.patch * patch -p1 env_array + E->env I've avoided changing any comments and derived variable names here, that will all be done in the next commit. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'pw/add-p-hunk-split-fix'

2022-02-09T22:20:59Z

"git add -p" rewritten in C regressed hunk splitting in some cases, which has been corrected. * pw/add-p-hunk-split-fix: builtin add -p: fix hunk splitting t3701: clean up hunk splitting tests