git/add-interactive.c, branch main

add-patch: allow disabling editing of hunks

2026-03-03T23:09:36Z

The "add-patch" mode allows the user to edit hunks to apply custom changes. This is incompatible with a new `git history split` command that we're about to introduce in a subsequent commit, so we need a way to disable this mode. Add a new flag to disable editing hunks. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

add-patch: split out `struct interactive_options`

2026-03-03T23:09:35Z

The `struct add_p_opt` is reused both by our infra for "git add -p" and "git add -i". Users of `run_add_i()` for example are expected to pass `struct add_p_opt`. This is somewhat confusing and raises the question of which options apply to what part of the stack. But things are even more confusing than that: while callers are expected to pass in `struct add_p_opt`, these options ultimately get used to initialize a `struct add_i_state` that is used by both subsystems. So we are basically going full circle here. Refactor the code and split out a new `struct interactive_options` that hosts common options used by both. These options are then applied to a `struct interactive_config` that hosts common configuration. This refactoring doesn't yet fully detangle the two subsystems from one another, as we still end up calling `init_add_i_state()` in the "git add -p" subsystem. This will be fixed in a subsequent commit. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'aa/add-p-no-auto-advance'

2026-03-03T19:08:13Z

"git add -p" learned a new mode that allows the user to revisit a file that was already dealt with. * aa/add-p-no-auto-advance: add-patch: allow interfile navigation when selecting hunks add-patch: allow all-or-none application of patches add-patch: modify patch_update_file() signature interactive -p: add new `--auto-advance` flag

interactive -p: add new `--auto-advance` flag

2026-02-17T18:48:36Z

When using the interactive add, reset, stash or checkout machinery, we do not have the option of reworking with a file when selecting hunks, because the session automatically advances to the next file or ends if we have just one file. Introduce the flag `--auto-advance` which auto advances by default, when interactively selecting patches with the '--patch' option. However, the `--no-auto-advance` option does not auto advance, thereby allowing users the option to rework with files. Signed-off-by: Abraham Samuel Adekunle Signed-off-by: Junio C Hamano

add-interactive: use repo_parse_tree_indirect()

2026-01-10T02:36:16Z

1b374ad71f (add-interactive: stop using `the_repository`, 2024-12-17) replaced explicit uses of the_repository. parse_tree_indirect() uses it internally, though, so call repo_parse_tree_indirect() instead and hand it the correct repository. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'sj/string-list'

2025-10-14T19:56:08Z

The "string-list" API function to find where a given string would be inserted got updated so that it can use unrealistically huge array index that would only fit in size_t but not int or ssize_t to achieve unstated goal. * sj/string-list: refs: enable sign compare warnings check string-list: change "string_list_find_insert_index" return type to "size_t" string-list: replace negative index encoding with "exact_match" parameter string-list: use bool instead of int for "exact_match"

string-list: change "string_list_find_insert_index" return type to "size_t"

2025-10-06T16:11:07Z

As "string_list_find_insert_index" is a simple wrapper of "get_entry_index" and the return type of "get_entry_index" is already "size_t", we could simply change its return type to "size_t". Update all callers to use size_t variables for storing the return value. The tricky fix is the loop condition in "mailmap.c" to properly handle "size_t" underflow by changing from `0 <= --i` to `i--`. Remove "DISABLE_SIGN_COMPARE_WARNINGS" from "mailmap.c" as it's no longer needed with the proper unsigned types. Signed-off-by: shejialuo Signed-off-by: Junio C Hamano

string-list: replace negative index encoding with "exact_match" parameter

2025-10-06T16:11:07Z

The "string_list_find_insert_index()" function is used to determine the correct insertion index for a new string within the string list. The function also doubles up to convey if the string is already existing in the list, this is done by returning a negative index "-1 -index". Users are expected to decode this information. This approach has several limitations: 1. It requires the callers to look into the detail of the function to understand how to decode the negative index encoding. 2. Using int for indices can cause overflow issues when dealing with large string lists. To address these limitations, change the function to return size_t for the index value and use a separate bool parameter to indicate whether the index refers to an existing entry or an insertion point. In some cases, the callers of "string_list_find_insert_index" only need the index position and don't care whether an exact match is found. However, "get_entry_index" currently requires a non-NULL "exact_match" parameter, forcing these callers to declare unnecessary variables. Let's allow callers to pass NULL for the "exact_match" parameter when they don't need this information, reducing unnecessary variable declarations in calling code. Signed-off-by: shejialuo Signed-off-by: Junio C Hamano

add-interactive: retain colorbool values longer

2025-09-17T01:00:25Z

Most of the diff code stores the decision about whether to show color as a git_colorbool, and evaluates it at point-of-use with want_color(). This timing is important for reasons explained in daa0c3d971 (color: delay auto-color decision until point of use, 2011-08-17). The add-interactive code instead converts immediately to strict boolean values using want_color(), and then evaluates those. This isn't wrong. Even though we pass the bool values to diff_use_color(), which expects a colorbool, the values are compatible. But it is unlike the rest of the color code, and is questionable from a type-system perspective (but C's typing between enums, ints, and bools is weak enough that the compiler does not complain). Let's switch it to the more usual way of calling want_color() at the point of use. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

color: use git_colorbool enum type to store colorbools

2025-09-17T00:59:53Z

We traditionally used "int" to store and pass around the values defined by "enum git_colorbool" (which were originally just #define macros). Using an int doesn't produce incorrect results, but using the actual enum makes the intent of the code more clear. It would be nice if the compiler could catch cases where we used the enum and an int interchangeably, since it's very easy to accidentally check the boolean true/false of a colorbool like: if (branch_use_color) This is wrong because GIT_COLOR_UNKNOWN and GIT_COLOR_AUTO evaluate to true in C, even though we may ultimately decide not to use color. But C is pretty happy to convert between ints and enums (even with various -Wenum-* warnings). So this sadly doesn't protect us from such mistakes, but it hopefully does make the code easier to read. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano