git/builtin/range-diff.c, branch jch

Merge branch 'kh/format-patch-range-diff-notes'

2025-10-14T19:56:09Z

"git format-patch --range-diff=... --notes=..." did not drive the underlying range-diff with correct --notes parameter, ending up comparing with different set of notes from its main patch output you would get from "git format-patch --notes=..." for a singleton patch. * kh/format-patch-range-diff-notes: format-patch: handle range-diff on notes correctly for single patches revision: add rdiff_log_arg to rev_info range-diff: rename other_arg to log_arg

Merge branch 'jk/color-variable-fixes'

2025-09-29T18:40:35Z

Some places in the code confused a variable that is *not* a boolean to enable color but is an enum that records what the user requested to do about color. A couple of bugs of this sort have been fixed, while the code has been cleaned up to prevent similar bugs in the future. * jk/color-variable-fixes: config: store want_color() result in a separate bool add-interactive: retain colorbool values longer color: return bool from want_color() color: use git_colorbool enum type to store colorbools pretty: use format_commit_context.auto_color as colorbool diff: stop passing ecbdata->use_color as boolean diff: pass o->use_color directly to fill_metainfo() diff: don't use diff_options.use_color as a strict bool diff: simplify color_moved check when flushing grep: don't treat grep_opt.color as a strict bool color: return enum from git_config_colorbool() color: use GIT_COLOR_* instead of numeric constants

range-diff: rename other_arg to log_arg

2025-09-25T18:34:11Z

Rename `other_arg` to `log_arg` in `range_diff_options` and related places. “Other argument” comes from bd361918 (range-diff: pass through --notes to `git log`, 2019-11-20) which introduced Git notes handling to git-range-diff(1) by passing that option on to git-log(1). And that kind of name might be fine in a local context. However, it was initially spread among multiple files, and is now[1] part of the `range_diff_options` struct. It is, prima facie, difficult to guess what “other” means, especially when just looking at the struct. But with a little reading we find out that it is used for `--[no-]notes` and `--diff-merges`, which are both passed on to git-log(1). We should just rename it to reflect this role; `log_arg` suggests, along with the `strvec` type, that it is used to pass extra arguments to git-log(1). † 1: since f1ce6c19 (range-diff: combine all options in a single data structure, 2021-02-05) Suggested-by: Junio C Hamano Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

color: use GIT_COLOR_* instead of numeric constants

2025-09-16T20:37:03Z

Long ago Git's decision to show color for a subsytem was stored in a tri-state variable: it could be true (1), false (0), or unknown (-1). But since daa0c3d971 (color: delay auto-color decision until point of use, 2011-08-17) we want to carry around a new state, "auto", which bases the decision on the tty-ness of stdout (rather than collapsing that "auto" state to a true/false immediately). That commit introduced a set of GIT_COLOR_* defines to represent each state: UNKNOWN, ALWAYS, NEVER, and AUTO. But it only used the AUTO value, and left alone code using bare 0/1/-1 values. And of course since then we've grown many new spots that use those bare values. Let's switch all of these to use the named constants. That should make the code a bit easier to read, as it is more obvious that we're representing a color decision. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

range-diff: add configurable memory limit for cost matrix

2025-08-29T16:46:07Z

When comparing large commit ranges (e.g., 250,000+ commits), range-diff attempts to allocate an n×n cost matrix that can exhaust available memory. For example, with 256,784 commits (n = 513,568), the matrix would require approximately 256GB of memory (513,568² × 4 bytes), causing either immediate segmentation faults due to integer overflow or system hangs. Add a memory limit check in get_correspondences() before allocating the cost matrix. This check uses the total size in bytes (n² × sizeof(int)) and compares it against a configurable maximum, preventing both excessive memory usage and integer overflow issues. The limit is configurable via a new --max-memory option that accepts human-readable sizes (e.g., "1G", "500M"). The default is 4GB for 64 bit systems and 2GB for 32 bit systems. This allows comparing ranges of approximately 32,000 (16,000) commits - generous for real-world use cases while preventing impractical operations. When the limit is exceeded, range-diff now displays a clear error message showing both the requested memory size and the maximum allowed, formatted in human-readable units for better user experience. Example usage: git range-diff --max-memory=1G branch1...branch2 git range-diff --max-memory=500M base..topic1 base..topic2 This approach was chosen over alternatives: - Pre-counting commits: Would require spawning additional git processes and reading all commits twice - Limiting by commit count: Less precise than actual memory usage - Streaming approach: Would require significant refactoring of the current algorithm This issue was previously discussed in: https://lore.kernel.org/git/RFC-cover-v2-0.5-00000000000-20211210T122901Z-avarab@gmail.com/ Acked-by: Johannes Schindelin Signed-off-by: Paulo Casaretto Signed-off-by: Junio C Hamano

config: drop `git_config()` wrapper

2025-07-23T15:15:18Z

In 036876a1067 (config: hide functions using `the_repository` by default, 2024-08-13) we have moved around a bunch of functions in the config subsystem that depend on `the_repository`. Those function have been converted into mere wrappers around their equivalent function that takes in a repository as parameter, and the intent was that we'll eventually remove those wrappers to make the dependency on the global repository variable explicit at the callsite. Follow through with that intent and remove `git_config()`. All callsites are adjusted so that they use `repo_config(the_repository, ...)` instead. While some callsites might already have a repository available, this mechanical conversion is the exact same as the current situation and thus cannot cause any regression. Those sites should eventually be cleaned up in a later patch series. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'js/range-diff-diff-merges'

2024-12-23T17:32:17Z

"git range-diff" learned to optionally show and compare merge commits in the ranges being compared, with the --diff-merges option. * js/range-diff-diff-merges: range-diff: introduce the convenience option `--remerge-diff` range-diff: optionally include merge commits' diffs in the analysis

range-diff: introduce the convenience option `--remerge-diff`

2024-12-16T16:45:48Z

Just like `git log`, now also `git range-diff` has that option as a shortcut for the common operation that would otherwise require the quite unwieldy (if theoretically "more correct") `--diff-mode=remerge` option. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

range-diff: optionally include merge commits' diffs in the analysis

2024-12-16T16:45:48Z

The `git log` command already offers support for including diffs for merges, via the `--diff-merges=` option. Let's add corresponding support for `git range-diff`, too. This makes it more convenient to spot differences between commit ranges that contain merges. This is especially true in scenarios with non-trivial merges, i.e. merges introducing changes other than, or in addition to, what merge ORT would have produced. Merging a topic branch that changes a function signature into a branch that added a caller of that function, for example, would require the merge commit itself to adjust that caller to the modified signature. In my code reviews, I found the `--diff-merges=remerge` option particularly useful. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

diff.h: fix index used to loop through unsigned integer

2024-12-06T11:20:03Z

The `struct diff_flags` structure is essentially an array of flags, all of which have the same type. We can thus use `sizeof()` to iterate through all of the flags, which we do in `diff_flags_or()`. But while the statement returns an unsigned integer, we used a signed integer to iterate through the flags, which generates a warning. Fix this by using `size_t` for the index instead. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano