summaryrefslogtreecommitdiffstats
path: root/t/t4256-am-format-flowed.sh (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-09-03The twelfth batchJunio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-29The eleventh batchJunio C Hamano1-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-28The tenth batchJunio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-28reftable: mark unused parameters in empty iterator functionsJeff King1-3/+3
These unused parameters were marked in a68ec8683a (reftable: mark unused parameters in virtual functions, 2024-08-17), but the functions were moved to a new file in a parallel branch via f2406c81b9 (reftable/generic: move generic iterator code into iterator interface, 2024-08-22). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-28t-reftable-block: mark unused argv/argcJeff King1-1/+1
This is conceptually the same as the cases in df9d638c24 (unit-tests: ignore unused argc/argv, 2024-08-17), but this unit test was migrated from the reftable tests in a parallel branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-26git-config.1: fix description of --regexp in synopsisJunio C Hamano2-2/+2
The synopsis says --regexp=<regexp> but the --regexp option is a Boolean that says "the name given is not literal, but a pattern to match the name". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-26git-config.1: --get-all description updateJunio C Hamano1-1/+1
"git config --get-all foo.bar" shows all values for the foo.bar variable, but does not give the variable name in each output entry. Hence it is equivalent to "git config get --all foo.bar", without "--show-names", in the more modern syntax. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-26The ninth batchJunio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-26A bit more topics for 2.46.x maintenance trackJunio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23remote: plug memory leaks at early returnsRené Scharfe1-8/+15
Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23The eighth batchJunio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/stack: fix segfault when reload with reused readers failsPatrick Steinhardt2-0/+82
It is expected that reloading the stack fails with concurrent writers, e.g. because a table that we just wanted to read just got compacted. In case we decided to reuse readers this will cause a segfault though because we unconditionally release all new readers, including the reused ones. As those are still referenced by the current stack, the result is that we will eventually try to dereference those already-freed readers. Fix this bug by incrementing the refcount of reused readers temporarily. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/stack: reorder swapping in the reloaded stack contentsPatrick Steinhardt1-15/+19
The code flow of how we swap in the reloaded stack contents is somewhat convoluted because we switch back and forth between swapping in different parts of the stack. Reorder the code to simplify it. We now first close and unlink the old tables which do not get reused before we update the stack to point to the new stack. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/reader: keep readers alive during iterationPatrick Steinhardt2-0/+52
The lifetime of a table iterator may survive the lifetime of a reader when the stack gets reloaded. Keep the reader from being released by increasing its refcount while the iterator is still being used. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/reader: introduce refcountingPatrick Steinhardt8-25/+46
It was recently reported that concurrent reads and writes may cause the reftable backend to segfault. The root cause of this is that we do not properly keep track of reftable readers across reloads. Suppose that you have a reftable iterator and then decide to reload the stack while iterating through the iterator. When the stack has been rewritten since we have created the iterator, then we would end up discarding a subset of readers that may still be in use by the iterator. The consequence is that we now try to reference deallocated memory, which of course segfaults. One way to trigger this is in t5616, where some background maintenance jobs have been leaking from one test into another. This leads to stack traces like the following one: + git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin AddressSanitizer:DEADLYSIGNAL ================================================================= ==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp 0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0) ==657994==The signal is caused by a READ memory access. #0 0x55f23e52ddf9 in get_var_int reftable/record.c:29 #1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170 #2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194 #3 0x55f23e54e72e in block_iter_next reftable/block.c:398 #4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240 #5 0x55f23e5573dc in table_iter_next reftable/reader.c:355 #6 0x55f23e5573dc in table_iter_next reftable/reader.c:339 #7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69 #8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123 #9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172 #10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175 #11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464 #12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13 #13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452 #14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623 #15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659 #16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133 #17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432 #18 0x55f23dba7764 in run_builtin git.c:484 #19 0x55f23dba7764 in handle_builtin git.c:741 #20 0x55f23dbab61e in run_argv git.c:805 #21 0x55f23dbab61e in cmd_main git.c:1000 #22 0x55f23dba4781 in main common-main.c:64 #23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360 #25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27) While it is somewhat awkward that the maintenance processes survive tests in the first place, it is totally expected that reftables should work alright with concurrent writers. Seemingly they don't. The only underlying resource that we need to care about in this context is the reftable reader, which is responsible for reading a single table from disk. These readers get discarded immediately (unless reused) when calling `reftable_stack_reload()`, which is wrong. We can only close them once we know that there are no iterators using them anymore. Prepare for a fix by converting the reftable readers to be refcounted. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/stack: fix broken refnames in `write_n_ref_tables()`Patrick Steinhardt1-0/+1
The `write_n_ref_tables()` helper function writes N references in separate tables. We never reset the computed name of those references though, leading us to end up with unexpected names. Fix this by resetting the buffer. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/reader: inline `reader_close()`Patrick Steinhardt3-12/+3
Same as with the preceding commit, we also provide a `reader_close()` function that allows the caller to close a reader without freeing it. This is unnecessary now that all users will have an allocated version of the reader. Inline it into `reftable_reader_free()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/reader: inline `init_reader()`Patrick Steinhardt3-99/+98
Most users use an allocated version of the `reftable_reader`, except for some tests. We are about to convert the reader to become refcounted though, and providing the ability to keep a reader on the stack makes this conversion harder than necessary. Update the tests to use `reftable_reader_new()` instead to prepare for this change. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/reader: rename `reftable_new_reader()`Patrick Steinhardt6-13/+13
Rename the `reftable_new_reader()` function to `reftable_reader_new()` to match our coding guidelines. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/stack: inline `stack_compact_range_stats()`Patrick Steinhardt1-12/+4
The only difference between `stack_compact_range_stats()` and `stack_compact_range()` is that the former updates stats on failure, whereas the latter doesn't. There are no callers anymore that do not want their stats updated though, making the indirection unnecessary. Inline the stat updates into `stack_compact_range()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/blocksource: drop malloc block sourcePatrick Steinhardt3-23/+2
The reftable blocksource provides a generic interface to read blocks via different sources, e.g. from disk or from memory. One of the block sources is the malloc block source, which can in theory read data from memory. We nowadays also have a strbuf block source though, which provides essentially the same functionality with better ergonomics. Adapt the only remaining user of the malloc block source in our tests to use the strbuf block source, instead, and remove the now-unused malloc block source. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23doc: replace 3 dash with correct 2 dash in git-config(1)Celeste Liu1-1/+1
Commit 4e51389000 (builtin/config: introduce "get" subcommand, 2024-05-06) introduced this typo. It uses 3 dashes for regexp argument instead of correct 2 dashes. Signed-off-by: Celeste Liu <CoelacanthusHex@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23send-pack: add new tracing regions for pushCalvin Wan1-3/+13
At $DAYJOB we experienced some slow pushes and needed additional trace data to diagnose them. Add trace2 regions for various sections of send_pack(). Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23fetch: add top-level trace2 regionsJosh Steadmon2-1/+19
At $DAYJOB we experienced some slow fetch operations and needed some additional data to help diagnose the issue. Add top-level trace2 regions for the various modes of operation of `git-fetch`. None of these regions are in recursive code, so any enclosed trace messages should only see their nesting level increase by one. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23trace2: implement trace2_printf() for event targetJosh Steadmon2-4/+35
The trace2 event target does not have an implementation for trace2_printf(). While the event target is for structured events, and trace2_printf() is for unstructured, human-readable messages, it may still be useful to wrap these unstructured messages in a structured JSON object. Among other things, it may reduce confusion when manually debugging using event trace data. Add a simple implementation for the event target that wraps trace2_printf() messages in a minimal JSON object. Document this in Documentation/technical/api-trace2.txt, and bump the event format version since we're adding a new event type. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22docs: explain the order of output in the batched mode of git-cat-file(1)ahmed akef1-3/+3
The batched mode of git-cat-file(1) reads multiple objects from stdin and prints their respective contents to stdout. The order in which those objects are printed is not documented and may not be immediately obvious to the user. Document it. Signed-off-by: ahmed akef <aemed.akef.1@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22diff-index: integrate with the sparse indexDerrick Stolee2-3/+16
The sparse index allows focusing the index data structure on the files present in the sparse-checkout, leaving only tree entries for directories not within the sparse-checkout. Each builtin needs a repository setting to indicate that it has been tested with the sparse index before Git will allow the index to be loaded into memory in its sparse form. This is a safety precaution. There are still some builtins that haven't been integrated due to the complexity of the integration and the lack of significant use. However, 'git diff-index' was neglected only because of initial data showing low usage. The diff machinery was already integrated and there is no more work to be done there but add some tests to be sure 'git diff-index' behaves as expected. For this purpose, we can follow the testing pattern used in 51ba65b5c35 (diff: enable and test the sparse index, 2021-12-06). One difference here is that we only verify that the sparse index case agrees with the full index case, but do not generate the expected output. The 'git diff' tests use the '--name-status' option to ease the creation of the expected output, but that's not an option for 'diff-index'. Since the underlying diff machinery is the same, a simple comparison is sufficient to give some coverage. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22transport: fix leaking negotiation tipsPatrick Steinhardt2-0/+5
We do not free negotiation tips in the transport's smart options. Fix this by freeing them on disconnect. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22transport: fix leaking arguments when fetching from bundlePatrick Steinhardt3-3/+5
In `fetch_refs_from_bundle()` we assemble a vector of arguments to pass to `unbundle()`, but never free it. And in theory we wouldn't have to because `unbundle()` already knows to free the vector for us. But it fails to do so when it exits early due to `verify_bundle()` failing. The calling convention that the arguments are freed by the callee and not the caller feels somewhat weird. Refactor the code such that it is instead the responsibility of the caller to free the vector, adapting the only two callsites where we pass extra arguments. This also fixes the memory leak. This memory leak gets hit in t5510, but fixing it isn't sufficient to make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/fetch: fix leaking transaction with `--atomic`Patrick Steinhardt2-4/+5
With the `--atomic` flag, we use a single ref transaction to commit all ref updates in git-fetch(1). The lifetime of transactions is somewhat weird: while `ref_transaction_abort()` will free the transaction, a call to `ref_transaction_commit()` won't. We thus have to manually free the transaction in the successful case. Adapt the code to free the transaction in the exit path to plug the resulting memory leak. As `ref_transaction_abort()` already freed the transaction for us, we have to unset the transaction when we hit that code path to not cause a double free. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22remote: fix leaking peer ref when expanding refmapPatrick Steinhardt5-0/+6
When expanding remote refs via the refspec in `get_expanded_map()`, we first copy the remote ref and then override its peer ref with the expanded name. This may cause a memory leak though in case the peer ref is already set, as this field is being copied by `copy_ref()`, as well. Fix the leak by freeing the peer ref before we re-assign the field. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22remote: fix leaks when matching refspecsPatrick Steinhardt2-14/+30
In `match_explicit()`, we try to match a source ref with a destination ref according to a refspec item. This matching sometimes requires us to allocate a new source spec so that it looks like we expect. And while we in some end up assigning this allocated ref as `peer_ref`, which hands over ownership of it to the caller, in other cases we don't. We neither free it though, causing a memory leak. Fix the leak by creating a common exit path where we can easily free the source ref in case it is allocated and hasn't been handed over to the caller. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22remote: fix leaking config stringsPatrick Steinhardt1-2/+38
We're leaking several config strings when assembling remotes, either because we do not free preceding values in case a config was set multiple times, or because we do not free them when releasing the remote state. This includes config strings for "branch" sections, "insteadOf", "pushInsteadOf", and "pushDefault". Plug those leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/fetch-pack: fix leaking refsPatrick Steinhardt1-8/+12
We build several ref lists in git-fetch-pack(1), but never free them. Fix those leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22sideband: fix leaks when configuring sideband colorsPatrick Steinhardt2-8/+8
We read a bunch of configs in `use_sideband_colors()` to configure the colors that Git should use. We never free the strings read from the config though, causing memory leaks. Refactor the code to use `git_config_get_string_tmp()` instead, which does not allocate memory. As we throw the strings away after parsing them anyway there is no need to use allocated strings. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/send-pack: fix leaking refspecsPatrick Steinhardt6-0/+9
We never free data associated with the assembled refspec in git-send-pack(1), causing a memory leak. Fix this. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22transport: fix leaking OID arrays in git:// transport dataPatrick Steinhardt3-0/+4
The transport data for the "git://" protocol contains two OID arrays that we never free, creating a memory leak. Plug them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: fix leaking multi-pack-indices in "read-midx"Patrick Steinhardt3-1/+10
Several of the subcommands of `test-helper read-midx` do not close the MIDX that they have opened, leading to memory leaks. Fix those. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/repack: fix leaks when computing packs to repackPatrick Steinhardt1-9/+27
When writing an MIDX in git-repack(1) we first collect all the pack names that we want to add to it in a string list. This list is marked as `NODUP`, which indicates that it will neither duplicate nor own strings added to it. In `write_midx_included_packs()` we then `insert()` strings via `xstrdup()` or `strbuf_detach()`, but the resulting strings will not be owned by anything and thus leak. Fix this issue by marking the list as `DUP` and using a local buffer to compute the pack names. This leak is hit in t5319, but plugging it is not sufficient to make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22midx-write: fix leaking hashfile on error casesPatrick Steinhardt1-12/+12
When writing the MIDX file we first create the `struct hashfile` used to write the trailer hash, and then afterwards we verify whether we can actually write the MIDX in the first place. When we decide that we can't, this leads to a memory leak because we never free the hash file contents. We could fix this by freeing the hashfile on the exit path. There is a better option though: we can simply move the checks for the error condition earlier. As there is no early exit between creating the hashfile and finalizing it anymore this is sufficient to fix the memory leak. While at it, also move around the block checking for `ctx.entries_nr`. This change is not required to fix the memory leak, but it feels natural to move together all massaging of parameters before we go with them and execute the actual logic. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/archive: fix leaking `OPT_FILENAME()` valuePatrick Steinhardt3-2/+7
The "--output" switch is an `OPT_FILENAME()` option, which allocates memory when specified by the user. But while we free the string when executed without the "--remote" switch, we don't otherwise because we return via a separate exit path that doesn't know to free it. Fix this by creating a common exit path. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/upload-archive: fix leaking args passed to `write_archive()`Patrick Steinhardt2-2/+16
In git-upload-archive(1), we pass an array of arguments to `write_archive()` to tell it what exactly to do. We don't ever clear the vector though, causing a memory leak. Furthermore though, the call to `write_archive()` may cause contents of the array to be modified, which would cause us to leak memory to allocated strings held by it. Fix the issue by having `write_archive()` create a shallow copy of `argv` before parsing the arguments. Like this, we won't modify the caller's array and can easily `strvec_clear()` it to plug these memory leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/merge-tree: fix leaking `-X` strategy optionsPatrick Steinhardt2-3/+11
The `-X` switch for git-merge-tree(1) will push each option into a local `xopts` vector that we then end up parsing. The vector never gets freed though, causing a memory leak. Plug it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22pretty: fix leaking key/value separator bufferPatrick Steinhardt2-0/+3
The `format_set_trailers_options()` function is responsible for parsing a custom pretty format for trailers. It puts the parsed options into a `struct process_trailer_options` structure, while the allocated memory required for this will be put into separate caller-provided arguments. It is thus the caller's responsibility to free the memory not via the options structure, but via the other parameters. While we do this alright for the separator and filter keys, we do not free the memory associated with the key/value separator. Fix this to plug this memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22pretty: fix memory leaks when parsing pretty formatsPatrick Steinhardt1-3/+9
When parsing pretty formats from the config we leak the name and user format whenever these are set multiple times. This is because we do not free any already-set value in case there is one. Plugging this leak for the name is trivial. For the user format we need to be a bit more careful, because we may end up assigning a pointer into the allocated region when the string is prefixed with either "format" or "tformat:". In order to make it safe to unconditionally free the user format we thus strdup the stripped string into the field instead of a pointer into the string. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22convert: fix leaks when resetting attributesPatrick Steinhardt2-0/+4
When resetting parsed gitattributes, we free the list of convert drivers parsed from the config. We only free some of the drivers' fields though and thus have memory leaks. Fix this by freeing all allocated convert driver fields to plug these memory leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22mailinfo: fix leaking header dataPatrick Steinhardt2-2/+16
We populate the `mailinfo` arrays `p_hdr_data` and `s_hdr_data` with data parsed from the mail headers. These arrays may end up being only partially populated with gaps in case some of the headers do not parse properly. This causes memory leaks because `strbuf_list_free()` will stop iterating once it hits the first `NULL` pointer in the backing array. Fix this by open-coding a variant of `strbuf_list_free()` that knows to iterate through all headers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22exec_cmd: RUNTIME_PREFIX on z/OS systemsD Harithamma3-0/+32
Enable Git to resolve its own binary location using __getprogramdir and getprogname. Since /proc is not a mandatory filesystem on z/OS, we cannot rely on the git_get_exec_path_procfs method to determine Git's executable path. To address this, we have implemented git_get_exec_path_zos, which resolves the executable path by extracting it from the current program's directory and filename. Signed-off-by: D Harithamma <harithamma.d@ibm.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22reftable/generic: drop interfacePatrick Steinhardt12-245/+0
The `reftable_table` interface provides a generic infrastructure that can abstract away whether the underlying table is a single table, or a merged table. This abstraction can make it rather hard to reason about the code. We didn't ever use it to implement the reftable backend, and with the preceding patches in this patch series we in fact don't use it at all anymore. Furthermore, it became somewhat useless with the recent refactorings that made it possible to seek reftable iterators multiple times, as these now provide generic access to tables for us. The interface is thus redundant and only brings unnecessary complexity with it. Remove the `struct reftable_table` interface and its associated functions. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: refactor to not use `struct reftable_table`Patrick Steinhardt1-15/+18
The `struct reftable_table` interface in our "reftable" test helper gets used such that we can easily print either a single table, or a merged stack. This generic interface is about to go away. Prepare the code for this change by using merged tables instead. When printing the stack we've already got one. When using a single table, we can create a merged table from it to adapt. This removes the last user of the generic interface. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>