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

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

revision.[ch]: provide and start using a release_revisions()

2022-04-14T06:56:08Z

The users of the revision.[ch] API's "struct rev_info" are a major source of memory leaks in the test suite under SANITIZE=leak, which in turn adds a lot of noise when trying to mark up tests with "TEST_PASSES_SANITIZE_LEAK=true". The users of that API are largely one-shot, e.g. "git rev-list" or "git log", or the "git checkout" and "git stash" being modified here For these callers freeing the memory is arguably a waste of time, but in many cases they've actually been trying to free the memory, and just doing that in a buggy manner. Let's provide a release_revisions() function for these users, and start migrating them over per the plan outlined in [1]. Right now this only handles the "pending" member of the struct, but more will be added in subsequent commits. Even though we only clear the "pending" member now, let's not leave a trap in code like the pre-image of index_differs_from(), where we'd start doing the wrong thing as soon as the release_revisions() learned to clear its "diffopt". I.e. we need to call release_revisions() after we've inspected any state in "struct rev_info". This leaves in place e.g. clear_pathspec(&rev.prune_data) in stash_working_tree() in builtin/stash.c, subsequent commits will teach release_revisions() to free "prune_data" and other members that in some cases are individually cleared by users of "struct rev_info" by reaching into its members. Those subsequent commits will remove the relevant calls to e.g. clear_pathspec(). We avoid amending code in index_differs_from() in diff-lib.c as well as wt_status_collect_changes_index(), has_unstaged_changes() and has_uncommitted_changes() in wt-status.c in a way that assumes that we are already clearing the "diffopt" member. That will be handled in a subsequent commit. 1. https://lore.kernel.org/git/87a6k8daeu.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

range-diff: plug memory leak in read_patches()

2022-03-04T21:24:19Z

Amend code added in d9c66f0b5bf (range-diff: first rudimentary implementation, 2018-08-13) to use a "goto cleanup" pattern. This makes for less code, and frees memory that we'd previously leak. The reason for changing free(util) to FREE_AND_NULL(util) is because at the end of the function we append the contents of "util" to a "struct string_list" if it's non-NULL. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

range-diff: plug memory leak in common invocation

2022-03-04T21:24:19Z

Create a public release_patch() version of the private free_patch() function added in 13b5af22f39 (apply: move libified code from builtin/apply.c to apply.{c,h}, 2016-04-22). Unlike the existing function this one doesn't free() the "struct patch" itself, so we can use it for variables on the stack. Use it in range-diff.c to fix a memory leak in common range-diff invocations, e.g.: git -P range-diff origin/master origin/next origin/seen Would emit several errors when compiled with SANITIZE=leak, but now runs cleanly. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

i18n: refactor "foo and bar are mutually exclusive"

2022-01-05T21:29:23Z

Use static strings for constant parts of the sentences. They are all turned into "cannot be used together". Signed-off-by: Jean-Noël Avila Reviewed-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'rs/range-diff-avoid-segfault-with-I'

2021-09-15T20:15:27Z

"git range-diff -I... " segfaulted, which has been corrected. * rs/range-diff-avoid-segfault-with-I: range-diff: avoid segfault with -I

range-diff: avoid segfault with -I

2021-09-07T20:03:13Z

output() reuses the same struct diff_options for multiple calls of diff_flush(). Set the option no_free to instruct it to keep the ignore regexes between calls and release them explicitly at the end. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jk/range-diff-fixes'

2021-08-30T23:06:05Z

"git range-diff" code clean-up. * jk/range-diff-fixes: range-diff: use ssize_t for parsed "len" in read_patches() range-diff: handle unterminated lines in read_patches() range-diff: drop useless "offset" variable from read_patches()

range-diff: use ssize_t for parsed "len" in read_patches()

2021-08-10T18:37:36Z

As we iterate through the buffer containing git-log output, parsing lines, we use an "int" to store the size of an individual line. This should be a size_t, as we have no guarantee that there is not a malicious 2GB+ commit-message line in the output. Overflowing this integer probably doesn't do anything _too_ terrible. We are not using the value to size a buffer, so the worst case is probably an out-of-bounds read from before the array. But it's easy enough to fix. Note that we have to use ssize_t here, since we also store the length result from parse_git_diff_header(), which may return a negative value for error. That function actually returns an int itself, which has a similar overflow problem, but I'll leave that for another day. Much of the apply.c code uses ints and should be converted as a whole; in the meantime, a negative return from parse_git_diff_header() will be interpreted as an error, and we'll bail (so we can't handle such a case, but given that it's likely to be malicious anyway, the important thing is we don't have any memory errors). Signed-off-by: Jeff King Acked-by: Derrick Stolee Signed-off-by: Junio C Hamano