git/range-diff.c, branch v2.40.0

range-diff: avoid compiler warning when char is unsigned

2023-02-28T22:43:05Z

Since 2b15969f61 (range-diff: let '--abbrev' option takes effect, 2023-02-20), GCC 11.3 on Ubuntu 22.04 on aarch64 warns (and errors out if the make variable DEVELOPER is set): range-diff.c: In function ‘output_pair_header’: range-diff.c:388:20: error: comparison is always false due to limited range of data type [-Werror=type-limits] 388 | if (abbrev < 0) | ^ cc1: all warnings being treated as errors That's because char is unsigned on that platform. Use int instead, just like in struct diff_options, to copy the value faithfully. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

range-diff: let '--abbrev' option takes effect

2023-02-21T22:02:05Z

As mentioned in 'git-range-diff.txt': "`git range-diff` also accepts the regular diff options (see linkgit:git-diff[1])...", but '--abbrev' is not in the "regular" scope. In Git, the "abbrev" of an object may not be a fixed value in different repositories, depending on the needs of the them(Linus mentioned in e6c587c7 in 2016: "the Linux kernel project needs 11 to 12 hexdigits" at that time ), that's why a user may want to display abbrev according to a specified length. Although a similar effect can be achieved through configuration (like: git -c core.abbrev=), but based on ease of use (many users may not know that the -c option can be specified) and the description in existing document, supporting users to directly use '--abbrev', could be a good way. Signed-off-by: Teng Long Signed-off-by: Junio C Hamano

diff: mark unused parameters in callbacks

2022-12-13T13:16:23Z

The diff code provides a format_callback interface, but not every callback needs each parameter (e.g., the "opt" and "data" parameters are frequently left unused). Likewise for the output_prefix callback, the low-level change/add_remove interfaces, the callbacks used by xdi_diff(), etc. Mark unused arguments in the callback implementations to quiet -Wunused-parameter. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ab/unused-annotation'

2022-09-14T19:56:39Z

Undoes 'jk/unused-annotation' topic and redoes it to work around Coccinelle rules misfiring false positives in unrelated codepaths. * ab/unused-annotation: git-compat-util.h: use "deprecated" for UNUSED variables git-compat-util.h: use "UNUSED", not "UNUSED(var)"

Merge branch 'jk/unused-annotation'

2022-09-14T19:56:39Z

Annotate function parameters that are not used (but cannot be removed for structural reasons), to prepare us to later compile with -Wunused warning turned on. * jk/unused-annotation: is_path_owned_by_current_uid(): mark "report" parameter as unused run-command: mark unused async callback parameters mark unused read_tree_recursive() callback parameters hashmap: mark unused callback parameters config: mark unused callback parameters streaming: mark unused virtual method parameters transport: mark bundle transport_options as unused refs: mark unused virtual method parameters refs: mark unused reflog callback parameters refs: mark unused each_ref_fn parameters git-compat-util: add UNUSED macro

git-compat-util.h: use "UNUSED", not "UNUSED(var)"

2022-09-01T17:49:48Z

As reported in [1] the "UNUSED(var)" macro introduced in 2174b8c75de (Merge branch 'jk/unused-annotation' into next, 2022-08-24) breaks coccinelle's parsing of our sources in files where it occurs. Let's instead partially go with the approach suggested in [2] of making this not take an argument. As noted in [1] "coccinelle" will ignore such tokens in argument lists that it doesn't know about, and it's less of a surprise to syntax highlighters. This undoes the "help us notice when a parameter marked as unused is actually use" part of 9b240347543 (git-compat-util: add UNUSED macro, 2022-08-19), a subsequent commit will further tweak the macro to implement a replacement for that functionality. 1. https://lore.kernel.org/git/220825.86ilmg4mil.gmgdl@evledraar.gmail.com/ 2. https://lore.kernel.org/git/220819.868rnk54ju.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

range-diff: optionally accept pathspecs

2022-08-26T16:49:26Z

The `git range-diff` command can be quite expensive, which is not a surprise given that the underlying algorithm to match up pairs of commits between the provided two commit ranges has a cubic runtime. Therefore it makes sense to restrict the commit ranges as much as possible, to reduce the amount of input to that O(N^3) algorithm. In chatty repositories with wide trees, this is not necessarily possible merely by choosing commit ranges wisely. Let's give users another option to restrict the commit ranges: by providing a pathspec. That helps in repositories with wide trees because it is likely that the user has a good idea which subset of the tree they are actually interested in. Example: git range-diff upstream/main upstream/seen HEAD -- range-diff.c This shows commits that are either in the local branch or in `seen`, but not in `main`, skipping all commits that do not touch `range-diff.c`. Note: Since we piggy-back the pathspecs onto the `other_arg` mechanism that was introduced to be able to pass through the `--notes` option to the revision machinery, we must now ensure that the `other_arg` array is appended at the end (the revision range must come before the pathspecs, if any). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

hashmap: mark unused callback parameters

2022-08-19T19:18:55Z

Hashmap comparison functions must conform to a particular callback interface, but many don't use all of their parameters. Especially the void cmp_data pointer, but some do not use keydata either (because they can easily form a full struct to pass when doing lookups). Let's mark these to make -Wunused-parameter happy. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'pb/range-diff-with-submodule'

2022-06-13T22:53:41Z

"git -c diff.submodule=log range-diff" did not show anything for submodules that changed in the ranges being compared, and "git -c diff.submodule=diff range-diff" did not work correctly. Fix this by including the "--submodule=short" output unconditionally to be compared. * pb/range-diff-with-submodule: range-diff: show submodule changes irrespective of diff.submodule

range-diff: show submodule changes irrespective of diff.submodule

2022-06-06T22:47:01Z

After generating diffs for each range to be compared using a 'git log' invocation, range-diff.c::read_patches looks for the "diff --git" header in those diffs to recognize the beginning of a new change. In a project with submodules, and with 'diff.submodule=log' set in the config, this header is missing for the diff of a changed submodule, so any submodule changes are quietly ignored in the range-diff. When 'diff.submodule=diff' is set in the config, the "diff --git" header is also missing for the submodule itself, but is shown for submodule content changes, which can easily confuse 'git range-diff' and lead to errors such as: error: git apply: bad git-diff - inconsistent old filename on line 1 error: could not parse git header 'diff --git path/to/submodule/and/some/file/within ' error: could not parse log for '@{u}..@{1}' Force the submodule diff format to its default ("short") when invoking 'git log' to generate the patches for each range, such that submodule changes are always detected. Add a test, including an invocation with '--creation-factor=100' to force the second commit in the range not to be considered a complete rewrite, in order to verify we do indeed get the "short" format. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano