git/builtin/diff-index.c, branch v2.40.2

cocci: apply "pending" index-compatibility to some "builtin/*.c"

2022-11-21T03:06:15Z

Apply "index-compatibility.pending.cocci" rule to "builtin/*", but exclude those where we conflict with in-flight changes. As a result some of them end up using only "the_index", so let's have them use the more narrow "USE_THE_INDEX_VARIABLE" rather than "USE_THE_INDEX_COMPATIBILITY_MACROS". Manual changes not made by coccinelle, that were squashed in: * Whitespace-wrap argument lists for repo_hold_locked_index(), repo_read_index_preload() and repo_refresh_and_write_index(), in cases where the line became too long after the transformation. * Change "refresh_cache()" to "refresh_index()" in a comment in "builtin/update-index.c". * For those whose call was followed by perror(""), change it to perror(""), referring to the new function. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

doc txt & -h consistency: add missing options and labels

2022-10-13T16:32:56Z

Fix various issues of SYNOPSIS and -h output syntax where: * Options such as --force were missing entirely * ...or the short option, such as -f * We said "opts" or "options", but could instead enumerate the (small) set of supported options * Options that were missing entirely (ls-remote's --sort=) As we can specify "--sort" multiple times (it's backed by a string-list" it should really be "[(--sort=)...]", which is what "git for-each-ref" lists it as, but let's leave that issue for a subsequent cleanup, and stop at making these consistent. Other "ref-filter.h" users share the same issue, e.g. "git-branch.txt". * For "verify-tag" and "verify-commit" we were missing the "--raw" option. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

built-ins: consistently add "\n" between "usage" and options

2022-10-13T16:32:54Z

Change commands in the "diff" family and "rev-list" to separate the usage information and option listing with an empty line. In the case of "git diff -h" we did this already (but let's use a consistent "\n" pattern there), for the rest these are now consistent with how the parse_options() API would emit usage. As we'll see in a subsequent commit this also helps to make the "git -h" output more easily machine-readable, as we can assume that the usage information is separated from the options by an empty line. Note that "COMMON_DIFF_OPTIONS_HELP" starts with a "\n", so the seeming omission of a "\n" here is correct, the second one is provided by the macro. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

revisions API: call diff_free(&revs->pruning) in revisions_release()

2022-04-14T06:56:10Z

Call diff_free() on the "pruning" member of "struct rev_info". Doing so makes several tests pass under SANITIZE=leak. This was also the last missing piece that allows us to remove the UNLEAK() in "cmd_diff" and "cmd_diff_index", which allows us to use those commands as a canary for general leaks in the revisions API. See [1] for further rationale, and 886e1084d78 (builtin/: add UNLEAKs, 2017-10-01) for the commit that added the UNLEAK() there. 1. https://lore.kernel.org/git/220218.861r00ib86.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

revisions API users: use release_revisions() with UNLEAK()

2022-04-14T06:56:09Z

Use a release_revisions() with those "struct rev_list" users which already "UNLEAK" the struct. It may seem odd to simultaneously attempt to free() memory, but also to explicitly ignore whether we have memory leaks in the same. As explained in preceding commits this is being done to use the built-in commands as a guinea pig for whether the release_revisions() function works as expected, we'd like to test e.g. whether we segfault as we change it. In subsequent commits we'll then remove these UNLEAK() as the function is made to free the memory that caused us to add them in the first place. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

diff-index: restore -c/--cc options handling

2021-09-07T18:11:35Z

This fixes 19b2517f (diff-merges: move specific diff-index "-m" handling to diff-index, 2021-05-21). That commit disabled handling of all diff for merges options in diff-index on an assumption that they are unused. However, it later appeared that -c and --cc, even though undocumented and not being covered by tests, happen to have had particular effect on diff-index output. Restore original -c/--cc options handling by diff-index. Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

diff-merges: move specific diff-index "-m" handling to diff-index

2021-05-21T00:24:14Z

Move specific handling of "-m" for diff-index to diff-index.c, so diff-merges is left to handle only diff for merges options. Being a better design by itself, this is especially essential in preparation for letting -m imply -p, as "diff-index -m" obviously should not imply -p, as it's entirely unrelated. To handle this, in addition to moving specific diff-index "-m" code out of diff-merges, we introduce new diff_merges_suppress_options_parsing() and call it before generic options processing in cmd_diff_index(). This new diff_merges_suppress_options_parsing() could then be reused and called before invocations of setup_revisions() for other commands that don't need --diff-merges options, but that's outside of the scope of these patch series. Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

Merge branch 'jc/diffcore-rotate'

2021-02-26T00:43:30Z

"git {diff,log} --{skip,rotate}-to=" allows the user to discard diff output for early paths or move them to the end of the output. * jc/diffcore-rotate: diff: --{rotate,skip}-to=

diff: --{rotate,skip}-to=

2021-02-16T17:30:42Z

In the implementation of "git difftool", there is a case where the user wants to start viewing the diffs at a specific path and continue on to the rest, optionally wrapping around to the beginning. Since it is somewhat cumbersome to implement such a feature as a post-processing step of "git diff" output, let's support it internally with two new options. - "git diff --rotate-to=C", when the resulting patch would show paths A B C D E without the option, would "rotate" the paths to shows patch to C D E A B instead. It is an error when there is no patch for C is shown. - "git diff --skip-to=C" would instead "skip" the paths before C, and shows patch to C D E. Again, it is an error when there is no patch for C is shown. - "git log [-p]" also accepts these two options, but it is not an error if there is no change to the specified path. Instead, the set of output paths are rotated or skipped to the specified path or the first path that sorts after the specified path. Signed-off-by: Junio C Hamano

MacOS: precompose_argv_prefix()

2021-02-03T22:09:37Z

The following sequence leads to a "BUG" assertion running under MacOS: DIR=git-test-restore-p Adiarnfd=$(printf 'A\314\210') DIRNAME=xx${Adiarnfd}yy mkdir $DIR && cd $DIR && git init && mkdir $DIRNAME && cd $DIRNAME && echo "Initial" >file && git add file && echo "One more line" >>file && echo y | git restore -p . Initialized empty Git repository in /tmp/git-test-restore-p/.git/ BUG: pathspec.c:495: error initializing pathspec_item Cannot close git diff-index --cached --numstat [snip] The command `git restore` is run from a directory inside a Git repo. Git needs to split the $CWD into 2 parts: The path to the repo and "the rest", if any. "The rest" becomes a "prefix" later used inside the pathspec code. As an example, "/path/to/repo/dir-inside-repå" would determine "/path/to/repo" as the root of the repo, the place where the configuration file .git/config is found. The rest becomes the prefix ("dir-inside-repå"), from where the pathspec machinery expands the ".", more about this later. If there is a decomposed form, (making the decomposing visible like this), "dir-inside-rep°a" doesn't match "dir-inside-repå". Git commands need to: (a) read the configuration variable "core.precomposeunicode" (b) precocompose argv[] (c) precompose the prefix, if there was any The first commit, 76759c7dff53 "git on Mac OS and precomposed unicode" addressed (a) and (b). The call to precompose_argv() was added into parse-options.c, because that seemed to be a good place when the patch was written. Commands that don't use parse-options need to do (a) and (b) themselfs. The commands `diff-files`, `diff-index`, `diff-tree` and `diff` learned (a) and (b) in commit 90a78b83e0b8 "diff: run arguments through precompose_argv" Branch names (or refs in general) using decomposed code points resulting in decomposed file names had been fixed in commit 8e712ef6fc97 "Honor core.precomposeUnicode in more places" The bug report from above shows 2 things: - more commands need to handle precomposed unicode - (c) should be implemented for all commands using pathspecs Solution: precompose_argv() now handles the prefix (if needed), and is renamed into precompose_argv_prefix(). Inside this function the config variable core.precomposeunicode is read into the global variable precomposed_unicode, as before. This reading is skipped if precomposed_unicode had been read before. The original patch for preocomposed unicode, 76759c7dff53, placed precompose_argv() into parse-options.c Now add it into git.c::run_builtin() as well. Existing precompose calls in diff-files.c and others may become redundant, and if we audit the callflows that reach these places to make sure that they can never be reached without going through the new call added to run_builtin(), we might be able to remove these existing ones. But in this commit, we do not bother to do so and leave these precompose callsites as they are. Because precompose() is idempotent and can be called on an already precomposed string safely, this is safer than removing existing calls without fully vetting the callflows. There is certainly room for cleanups - this change intends to be a bug fix. Cleanups needs more tests in e.g. t/t3910-mac-os-precompose.sh, and should be done in future commits. [1] git-bugreport-2021-01-06-1209.txt (git can't deal with special characters) [2] https://lore.kernel.org/git/A102844A-9501-4A86-854D-E3B387D378AA@icloud.com/ Reported-by: Daniel Troger Helped-By: Philippe Blain Signed-off-by: Torsten Bögershausen Signed-off-by: Junio C Hamano