git/apply.c, branch v2.47.2

Merge branch 'ps/apply-leakfix'

2024-09-25T17:37:10Z

"git apply" had custom buffer management code that predated before use of strbuf got widespread, which has been updated to use strbuf, which also plugged some memory leaks. * ps/apply-leakfix: apply: refactor `struct image` to use a `struct strbuf` apply: rename members that track line count and allocation length apply: refactor code to drop `line_allocated` apply: introduce macro and function to init images apply: rename functions operating on `struct image` apply: reorder functions to move image-related things together

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

2024-09-23T17:35:05Z

Code clean-up. * ps/environ-wo-the-repository: (21 commits) environment: stop storing "core.notesRef" globally environment: stop storing "core.warnAmbiguousRefs" globally environment: stop storing "core.preferSymlinkRefs" globally environment: stop storing "core.logAllRefUpdates" globally refs: stop modifying global `log_all_ref_updates` variable branch: stop modifying `log_all_ref_updates` variable repo-settings: track defaults close to `struct repo_settings` repo-settings: split out declarations into a standalone header environment: guard state depending on a repository environment: reorder header to split out `the_repository`-free section environment: move `set_git_dir()` and related into setup layer environment: make `get_git_namespace()` self-contained environment: move object database functions into object layer config: make dependency on repo in `read_early_config()` explicit config: document `read_early_config()` and `read_very_early_config()` environment: make `get_git_work_tree()` accept a repository environment: make `get_graft_file()` accept a repository environment: make `get_index_file()` accept a repository environment: make `get_object_directory()` accept a repository environment: make `get_git_common_dir()` accept a repository ...

apply: refactor `struct image` to use a `struct strbuf`

2024-09-17T20:53:30Z

The `struct image` uses a character array to track the pre- or postimage of a patch operation. This has multiple downsides: - It is somewhat hard to track memory ownership. In fact, we have several memory leaks in git-apply(1) because we do not (and cannot easily) free the buffer in all situations. - We have to reinvent the wheel and manually implement a lot of functionality that would already be provided by `struct strbuf`. - We have to carefully track whether `update_pre_post_images()` can do an in-place update of the postimage or whether it has to allocate a new buffer for it. This is all rather cumbersome, and especially `update_pre_post_images()` is really hard to understand as a consequence even though what it is doing is rather trivial. Refactor the code to use a `struct strbuf` instead, addressing all of the above. Like this we can easily perform in-place updates in all situations, the logic to perform those updates becomes way simpler and the lifetime of the buffer becomes a ton easier to track. This refactoring also plugs some leaking buffers as a side effect. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

apply: rename members that track line count and allocation length

2024-09-17T20:53:30Z

The `struct image` has two members `nr` and `alloc` that track the number of lines as well as how large its array is. It is somewhat easy to confuse these members with `len` though, which tracks the length of the `buf` member. Rename these members to `line_nr` and `line_alloc` respectively to avoid confusion. This is in line with how we typically name variables that track an array in this way. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

apply: refactor code to drop `line_allocated`

2024-09-17T20:53:30Z

The `struct image` has two members `line` and `line_allocated`. The former member is the one that should be used throughout the code, whereas the latter one is used to track whether the lines have been allocated or not. In practice, the array of lines is always allocated. The reason why we have `line_allocated` is that `remove_first_line()` will advance the array pointer to drop the first entry, and thus it points into the array instead of to the array header. Refactor the function to use memmove(3P) instead, which allows us to get rid of this double bookkeeping. This is less efficient, but I doubt that this matters much in practice. If this judgement call is found to be wrong at a later point in time we can likely refactor the surrounding loop such that we first calculate the number of leading context lines to remove and then remove them in a single call to memmove(3P). Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

apply: introduce macro and function to init images

2024-09-17T20:53:29Z

We're about to convert the `struct image` to gain a `struct strbuf` member, which requires more careful initialization than just memsetting it to zeros. Introduce the `IMAGE_INIT` macro and `image_init()` function to prepare for this change. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

apply: rename functions operating on `struct image`

2024-09-17T20:53:29Z

Rename functions operating on `struct image` to have a `image_` prefix to match our modern code style. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

apply: reorder functions to move image-related things together

2024-09-17T20:53:29Z

While most of the functions relating to `struct image` are relatively close to one another, `fuzzy_matchlines()` sits in between those even though it is rather unrelated. Reorder functions such that `struct image`-related functions are next to each other. While at it, move `clear_image()` to the top such that it is close to the struct definition itself. This makes this lifecycle-related thing easy to discover. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

environment: make `get_git_dir()` accept a repository

2024-09-12T17:15:39Z

The `get_git_dir()` function retrieves the path to the Git directory for `the_repository`. Make it accept a `struct repository` such that it can work on arbitrary repositories and make it part of the repository subsystem. This reduces our reliance on `the_repository` and clarifies scope. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

apply: support --ours, --theirs, and --union for three-way merges

2024-09-09T17:07:24Z

--ours, --theirs, and --union are already supported in `git merge-file` for automatically resolving conflicts in favor of one version or the other, instead of leaving conflict markers in the file. Support them in `git apply -3` as well because the two commands do the same kind of file-level merges. In case in the future --ours, --theirs, and --union gain a meaning outside of three-way-merges, they do not imply --3way but rather must be specified alongside it. Signed-off-by: Alex Henrie Signed-off-by: Junio C Hamano