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

add-interactive: respect color.diff for diff coloring

2025-09-08T21:00:32Z

The old perl git-add--interactive.perl script used the color.diff config option to decide whether to color diffs (and if not set, it fell back to the value of color.ui via git-config's --get-colorbool option). When we switched to the builtin version, this was lost: we respect only color.ui. So for example: git -c color.diff=false add -p would color the diff, even when it should not. The culprit is this line in add-interactive.c's parse_diff(): if (want_color_fd(1, -1)) That "-1" means "no config has been set", which causes it to fall back to the color.ui setting. We should instead be passing the value of color.diff. But the problem is that we never even parse that config option! Instead the builtin interactive code parses only the value of color.interactive, which is used for prompts and other messages. One could perhaps argue that this should cover interactive diff coloring, too, but historically it did not. The perl script treated color.interactive and color.diff separately. So we should grab the values for both, keeping separate fields in our add_i_state variable, rather than a single use_color field. We also load individual color slots (e.g., color.interactive.prompt), leaving them as the empty string when color is disabled. This happens via the init_color() helper in add-interactive, which checks that use_color field. Now that there are two such fields, we need to pass the appropriate one for each color. The colors are mostly easy to divide up; color.interactive.* follows color.interactive, and color.diff.* follows color.diff. But the "reset" color is tricky. It is used for both types of coloring, but the two can be configured independently. So we introduce two separate reset colors, and use each in the appropriate spot. There are two new tests. The first enables interactive prompt colors but disables color.diff. We should see a colored prompt but not a colored diff, showing that we are now respecting color.diff (and not color.interactive or color.ui). The second does the opposite. We disable color.interactive but turn on color.diff with a custom fragment color. When we split a hunk, the interactive code has to re-color the hunk header, which lets us check that we correctly loaded the color.diff.frag config based on color.diff, not color.interactive. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add-patch: add diff.context command line overrides

2025-07-29T15:52:45Z

This patch compliments the previous commit, where builtins that use add-patch infrastructure now respect diff.context and diff.interHunkContext file configurations. In particular, this patch helps users who don't want to set persistent context configurations or just want a way to override them on a one-time basis, by allowing the relevant builtins to accept corresponding command line options that override the file configurations. This mimics commands such as diff and log, which allow for both context file configuration and command line overrides. Signed-off-by: Leon Michalak Signed-off-by: Junio C Hamano

add-patch: respect diff.context configuration

2025-07-29T15:52:45Z

Various builtins that use add-patch infrastructure do not respect the user's diff.context and diff.interHunkContext file configurations. The user may be used to seeing their diffs with customized context size, but not in the patches "git add -p" shows them to pick from. Teach add-patch infrastructure to read these configuration variables and pass their values when spawning the underlying plumbing commands as their command line option. Signed-off-by: Leon Michalak Signed-off-by: Junio C Hamano

pager: stop using `the_repository`

2024-12-18T18:44:30Z

Stop using `the_repository` in the "pager" subsystem by passing in a repository when setting up the pager and when configuring it. Adjust callers accordingly by using `the_repository`. While there may be some callers that have a repository available in their context, this trivial conversion allows for easier verification and bubbles up the use of `the_repository` by one level. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

global: mark code units that generate warnings with `-Wsign-compare`

2024-12-06T11:20:02Z

Mark code units that generate warnings with `-Wsign-compare`. This allows for a structured approach to get rid of all such warnings over time in a way that can be easily measured. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'ps/config-wo-the-repository'

2024-08-23T16:02:34Z

Use of API functions that implicitly depend on the_repository object in the config subsystem has been rewritten to pass a repository object through the callchain. * ps/config-wo-the-repository: config: hide functions using `the_repository` by default global: prepare for hiding away repo-less config functions config: don't depend on `the_repository` with branch conditions config: don't have setters depend on `the_repository` config: pass repo to functions that rename or copy sections config: pass repo to `git_die_config()` config: pass repo to `git_config_get_expiry_in_days()` config: pass repo to `git_config_get_expiry()` config: pass repo to `git_config_get_max_percent_split_change()` config: pass repo to `git_config_get_split_index()` config: pass repo to `git_config_get_index_threads()` config: expose `repo_config_clear()` config: introduce missing setters that take repo as parameter path: hide functions using `the_repository` by default path: stop relying on `the_repository` in `worktree_git_path()` path: stop relying on `the_repository` when reporting garbage hooks: remove implicit dependency on `the_repository` editor: do not rely on `the_repository` for interactive edits path: expose `do_git_common_path()` as `repo_common_pathv()` path: expose `do_git_path()` as `repo_git_pathv()`

editor: do not rely on `the_repository` for interactive edits

2024-08-13T17:01:00Z

We implicitly rely on `the_repository` when editing a file interactively because we call `git_path()`. Adapt the function to instead take a `struct repository` as a parameter so that we can remove this hidden dependency. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'rj/add-p-pager'

2024-08-08T17:41:18Z

A 'P' command to "git add -p" that passes the patch hunk to the pager has been added. * rj/add-p-pager: add-patch: render hunks through the pager pager: introduce wait_for_pager pager: do not close fd 2 unnecessarily add-patch: test for 'p' command

Merge branch 'pw/add-patch-with-suppress-blank-empty'

2024-07-31T20:34:17Z

"git add -p" by users with diff.suppressBlankEmpty set to true failed to parse the patch that represents an unmodified empty line with an empty line (not a line with a single space on it), which has been corrected. * pw/add-patch-with-suppress-blank-empty: add-patch: use normalize_marker() when recounting edited hunk add-patch: handle splitting hunks with diff.suppressBlankEmpty

add-patch: render hunks through the pager

2024-07-25T16:03:00Z

Make the print command trigger the pager when invoked using a capital 'P', to make it easier for the user to review long hunks. Note that if the PAGER ends unexpectedly before we've been able to send the payload, perhaps because the user is not interested in the whole thing, we might receive a SIGPIPE, which would abruptly and unexpectedly terminate the interactive session for the user. Therefore, we need to ignore a possible SIGPIPE signal. Add a test for this, in addition to the test for normal operation. For the SIGPIPE test, we need to make sure that we completely fill the operating system's buffer, otherwise we might not trigger the SIGPIPE signal. The normal size of this buffer in different OSs varies from a few KBs to 1MB. Use a payload large enough to guarantee that we exceed this limit. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano