summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-11-25completion: complete '--tool-help' in 'git mergetool'Philippe Blain1-1/+1
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25fetch set_head: handle mirrored bare repositoriesBence Ferdinandy2-5/+21
When adding a remote to bare repository with "git remote add --mirror", running fetch will fail to update HEAD to the remote's HEAD, since it does not know how to handle bare repositories. On the other hand HEAD already has content, since "git init --bare" has already set HEAD to whatever is the default branch set for the user. Unless this - by chance - is the same as the remote's HEAD, HEAD will be pointing to a bad symref. Teach set_head to handle bare repositories, by overwriting HEAD so it mirrors the remote's HEAD. Note, that in this case overriding the local HEAD reference is necessary, since HEAD will exist before fetch can be run, but this should not be an issue, since the whole purpose of --mirror is to be an exact mirror of the remote, so following any changes to HEAD makes sense. Also note, that although "git remote set-head" also fails when trying to update the remote's locally tracked HEAD in a mirrored bare repository, the usage of the command does not make much sense after this patch: fetch will update the remote HEAD correctly, and setting it manually to something else is antithetical to the concept of mirroring. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25fetch: set remote/HEAD if it does not existBence Ferdinandy12-17/+203
When cloning a repository remote/HEAD is created, but when the user creates a repository with git init, and later adds a remote, remote/HEAD is only created if the user explicitly runs a variant of "remote set-head". Attempt to set remote/HEAD during fetch, if the user does not have it already set. Silently ignore any errors. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25refs: add create_only option to refs_update_symref_extendedBence Ferdinandy3-11/+26
Allow the caller to specify that it only wants to update the symref if it does not already exist. Silently ignore the error from the transaction API if the symref already exists. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25refs: add TRANSACTION_CREATE_EXISTS errorBence Ferdinandy3-11/+23
Currently there is only one special error for transaction, for when there is a naming conflict, all other errors are dumped under a generic error. Add a new special error case for when the caller requests the reference to be updated only when it does not yet exist and the reference actually does exist. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25remote set-head: better output for --autoBence Ferdinandy2-13/+109
Currently, set-head --auto will print a message saying "remote/HEAD set to branch", which implies something was changed. Change the output of --auto, so the output actually reflects what was done: a) set a previously unset HEAD, b) change HEAD because remote changed or c) no updates. As edge cases, if HEAD is changed from a previous symbolic reference that was not a remote branch, explicitly call attention to this fact, and also notify the user if the previous reference was not a symbolic reference. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25remote set-head: refactor for readabilityBence Ferdinandy1-11/+12
Make two different readability refactors: Rename strbufs "buf" and "buf2" to something more explanatory. Instead of calling get_main_ref_store(the_repository) multiple times, call it once and store the result in a new refs variable. Although this change probably offers some performance benefits, the main purpose is to shorten the line lengths of function calls using this variable. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25refs: atomically record overwritten ref in update_symrefBence Ferdinandy2-2/+24
When updating a symref with update_symref it's currently not possible to know for sure what was the previous value that was overwritten. Extend refs_update_symref under a new function name, to record the value after the ref has been locked if the caller of refs_update_symref_extended requests it via a new variable in the function call. Make the return value of the function notify the caller, if the previous value was actually not a symbolic reference. Keep the original refs_update_symref function with the same signature, but now as a wrapper around refs_update_symref_extended. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25refs: standardize output of refs_read_symbolic_refBence Ferdinandy4-6/+23
When the symbolic reference we want to read with refs_read_symbolic_ref is actually not a symbolic reference, the files and the reftable backends return different values (1 and -1 respectively). Standardize the returned values so that 0 is success, -1 is a generic error and -2 is that the reference was actually non-symbolic. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25t/t5505-remote: test failure of set-headBence Ferdinandy2-1/+13
The test coverage was missing a test for the failure branch of remote set-head auto's output. Add the missing text and while we are at it, correct a small grammatical mistake in the error's output ("setup" is the noun, "set up" is the verb). Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-25t/t5505-remote: set default branch to mainBence Ferdinandy1-0/+3
Consider the bare repository called "mirror" in the test. Running `git remote add --mirror -f origin ../one` will not change HEAD, consequently if init.defaultBranch is not the same as what HEAD in the remote ("one"), HEAD in "mirror" will be pointing to a non-existent reference. Hence if "mirror" is used as a remote by yet another repository, ls-remote will not show HEAD. On the other hand, if init.defaultBranch happens to match HEAD in "one", then ls-remote will show HEAD. Since the "ci/run-build-and-tests.sh" script globally exports GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main for some (but not all) jobs, there may be a drift in some tests between how the test repositories are set up in the CI and during local testing, if the test itself uses "master" as default instead of "main". In particular, this happens in t5505-remote.sh. This issue does not manifest currently, as the test does not do any remote HEAD manipulation where this would come up, but should such things be added, a locally passing test would break the CI and vice-versa. Set GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main in t5505-remote to be consistent with the CI. Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-24gitk: check main window visibility before waiting for it to showTobias Pietzsch1-1/+1
If the main window is already visible when gitk waits for it to become visible, gitk hangs forever. This commit adds a check whether the window is already visible. See https://wiki.tcl-lang.org/page/tkwait+visibility Signed-off-by: Tobias Pietzsch <pietzsch@mycroft.speedport.ip> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2024-11-24Makefile(s): avoid recipe prefix in conditional statementsTaylor Blau1-2/+2
In GNU Make commit 07fcee35 ([SV 64815] Recipe lines cannot contain conditional statements, 2023-05-22) and following, conditional statements may no longer be preceded by a tab character (which Make refers to as the recipe prefix). There are a handful of spots in our various Makefile(s) which will break in a future release of Make containing 07fcee35. For instance, trying to compile the pre-image of this patch with the tip of make.git results in the following: $ make -v | head -1 && make GNU Make 4.4.90 config.mak.uname:842: *** missing 'endif'. Stop. The kernel addressed this issue in 82175d1f9430 (kbuild: Replace tabs with spaces when followed by conditionals, 2024-01-28). Address the issues in Git's tree by applying the same strategy. When a conditional word (ifeq, ifneq, ifdef, etc.) is preceded by one or more tab characters, replace each tab character with 8 space characters with the following: find . -type f -not -path './.git/*' -name Makefile -or -name '*.mak' | xargs perl -i -pe ' s/(\t+)(ifn?eq|ifn?def|else|endif)/" " x (length($1) * 8) . $2/ge unless /\\$/ ' The "unless /\\$/" removes any false-positives (like "\telse \" appearing within a shell script as part of a recipe). After doing so, Git compiles on newer versions of Make: $ make -v | head -1 && make GNU Make 4.4.90 GIT_VERSION = 2.44.0.414.gfac1dc44ca9 [...] $ echo $? 0 Reported-by: Dario Gjorgjevski <dario.gjorgjevski@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Cherry-picked-from: 728b9ac0c3b93aaa4ea80280c591deb198051785 Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2024-11-24doc: switch links to httpsJosh Soref1-1/+1
These sites offer https versions of their content. Using the https versions provides some protection for users. Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Cherry-picked-from: d05b08cd52cfda627f1d865bdfe6040a2c9521b5 Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2024-11-24doc: update links to current pagesJosh Soref1-1/+1
It's somewhat traditional to respect sites' self-identification. Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Cherry-picked-from: 65175d9ea26bebeb9d69977d0e75efc0e88dbced Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2024-11-22The eleventh batchJunio C Hamano1-0/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-22Merge branch 'tb/multi-pack-reuse-dupfix'Junio C Hamano2-55/+62
Object reuse code based on multi-pack-index sent an unwanted copy of object. * tb/multi-pack-reuse-dupfix: pack-objects: only perform verbatim reuse on the preferred pack t5332-multi-pack-reuse.sh: demonstrate duplicate packing failure
2024-11-22Merge branch 'sm/difftool'Junio C Hamano2-4/+6
Use of some uninitialized variables in "git difftool" has been corrected. * sm/difftool: builtin/difftool: intialize some hashmap variables
2024-11-22Merge branch 'jk/fetch-prefetch-double-free-fix'Junio C Hamano6-38/+30
Double-free fix. * jk/fetch-prefetch-double-free-fix: refspec: store raw refspecs inside refspec_item refspec: drop separate raw_nr count fetch: adjust refspec->raw_nr when filtering prefetch refspecs
2024-11-22Merge branch 'jk/test-malloc-debug-check'Junio C Hamano1-47/+50
Avoid build/test breakage on a system without working malloc debug support dynamic library. * jk/test-malloc-debug-check: test-lib: move malloc-debug setup after $PATH setup test-lib: check malloc debug LD_PRELOAD before using
2024-11-22t/perf: use 'test_file_size' in more placesTaylor Blau2-2/+2
The perf test suite prefers to use test_file_size over 'wc -c' when inside of a test_size block. One advantage is that accidentally writign "wc -c file" (instead of "wc -c <file") does not inadvertently break the tests (since the former will include the filename in the output of wc). Both of the two uses of test_size use "wc -c", but let's convert those to the more conventional test_file_size helper instead. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-22pack-bitmap.c: typofix in `find_boundary_objects()`Taylor Blau1-1/+1
In the boundary-based bitmap traversal, we use the given 'rev_info' structure to first do a commit-only walk in order to determine the boundary between interesting and uninteresting objects. That walk only looks at commit objects, regardless of the state of revs->blob_objects, revs->tree_objects, and so on. In order to do this, we store the state of these variables in temporary fields before setting them back to zero, performing the traversal, and then setting them back. But there is a typo here that dates back to b0afdce5da (pack-bitmap.c: use commit boundary during bitmap traversal, 2023-05-08), where we incorrectly store the value of the "tags" field as "revs->blob_objects". This could lead to problems later on if, say, the caller wants tag objects but *not* blob objects. In the pre-image behavior, we'd set revs->tag_objects back to the old value of revs->blob_objects, thus emitting fewer objects than expected back to the caller. Fix that by correctly assigning the value of 'revs->tag_objects' to the 'tmp_tags' field. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21t: remove TEST_PASSES_SANITIZE_LEAK annotationsPatrick Steinhardt928-928/+0
Now that the default value for TEST_PASSES_SANITIZE_LEAK is `true` there is no longer a need to have that variable declared in all of our tests. Drop it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21test-lib: unconditionally enable leak checkingPatrick Steinhardt4-97/+1
Over the last two releases we have plugged a couple hundred of memory leaks exposed by the Git test suite. With the preceding commits we have finally fixed the last leak exposed by our test suite, which means that we are now basically leak free wherever we have branch coverage. From hereon, the Git test suite should ideally stay free of memory leaks. Most importantly, any test suite that is being added should automatically be subject to the leak checker, and if that test does not pass it is a strong signal that the added code introduced new memory leaks and should not be accepted without further changes. Drop the infrastructure around TEST_PASSES_SANITIZE_LEAK to reflect this new requirement. Like this, all test suites will be subject to the leak checker by default. This is being intentionally strict, but we still have an escape hatch: the SANITIZE_LEAK prerequisite. There is one known case in t5601 where the leak sanitizer itself is buggy, so adding this prereq in such cases is acceptable. Another acceptable situation is when a newly added test uncovers preexisting memory leaks: when fixing that memory leak would be sufficiently complicated it is fine to annotate and document the leak accordingly. But in any case, the burden is now on the patch author to explain why exactly they have to add the SANITIZE_LEAK prerequisite. The TEST_PASSES_SANITIZE_LEAK annotations will be dropped in the next patch. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21t: remove unneeded !SANITIZE_LEAK prerequisitesPatrick Steinhardt3-11/+11
We have a couple of !SANITIZE_LEAK prerequisites for tests that used to fail due to memory leaks. These have all been fixed by now, so let's drop the prerequisite. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21t: mark some tests as leak freePatrick Steinhardt2-0/+2
Both t5558 and t5601 are leak-free starting with 6dab49b9fb (bundle-uri: plug leak in unbundle_from_file(), 2024-10-10). Mark them accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21t5601: work around leak sanitizer issuePatrick Steinhardt1-11/+15
When running t5601 with the leak checker enabled we can see a hang in our CI systems. This hang seems to be system-specific, as I cannot reproduce it on my own machine. As it turns out, the issue is in those testcases that exercise cloning of `~repo`-style paths. All of the testcases that hang eventually end up interpreting "repo" as the username and will call getpwnam(3p) with that username. That should of course be fine, and getpwnam(3p) should just return an error. But instead, the leak sanitizer seems to be recursing while handling a call to `free()` in the NSS modules: #0 0x00007ffff7fd98d5 in _dl_update_slotinfo (req_modid=1, new_gen=2) at ../elf/dl-tls.c:720 #1 0x00007ffff7fd9ac4 in update_get_addr (ti=0x7ffff7a91d80, gen=<optimized out>) at ../elf/dl-tls.c:916 #2 0x00007ffff7fdc85c in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #3 0x00007ffff7a27e04 in __lsan::GetAllocatorCache () at ../../../../src/libsanitizer/lsan/lsan_linux.cpp:27 #4 0x00007ffff7a2b33a in __lsan::Deallocate (p=0x0) at ../../../../src/libsanitizer/lsan/lsan_allocator.cpp:127 #5 __lsan::lsan_free (p=0x0) at ../../../../src/libsanitizer/lsan/lsan_allocator.cpp:220 ... #261505 0x00007ffff7fd99f2 in free (ptr=<optimized out>) at ../include/rtld-malloc.h:50 #261506 _dl_update_slotinfo (req_modid=1, new_gen=2) at ../elf/dl-tls.c:822 #261507 0x00007ffff7fd9ac4 in update_get_addr (ti=0x7ffff7a91d80, gen=<optimized out>) at ../elf/dl-tls.c:916 #261508 0x00007ffff7fdc85c in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #261509 0x00007ffff7a27e04 in __lsan::GetAllocatorCache () at ../../../../src/libsanitizer/lsan/lsan_linux.cpp:27 #261510 0x00007ffff7a2b33a in __lsan::Deallocate (p=0x5020000001e0) at ../../../../src/libsanitizer/lsan/lsan_allocator.cpp:127 #261511 __lsan::lsan_free (p=0x5020000001e0) at ../../../../src/libsanitizer/lsan/lsan_allocator.cpp:220 #261512 0x00007ffff793da25 in module_load (module=0x515000000280) at ./nss/nss_module.c:188 #261513 0x00007ffff793dee5 in __nss_module_load (module=0x515000000280) at ./nss/nss_module.c:302 #261514 __nss_module_get_function (module=0x515000000280, name=name@entry=0x7ffff79b9128 "getpwnam_r") at ./nss/nss_module.c:328 #261515 0x00007ffff793e741 in __GI___nss_lookup_function (fct_name=<optimized out>, ni=<optimized out>) at ./nss/nsswitch.c:137 #261516 __GI___nss_next2 (ni=ni@entry=0x7fffffffa458, fct_name=fct_name@entry=0x7ffff79b9128 "getpwnam_r", fct2_name=fct2_name@entry=0x0, fctp=fctp@entry=0x7fffffffa460, status=status@entry=0, all_values=all_values@entry=0) at ./nss/nsswitch.c:120 #261517 0x00007ffff794c6a7 in __getpwnam_r (name=name@entry=0x501000000060 "repo", resbuf=resbuf@entry=0x7ffff79fb320 <resbuf>, buffer=<optimized out>, buflen=buflen@entry=1024, result=result@entry=0x7fffffffa4b0) at ../nss/getXXbyYY_r.c:343 #261518 0x00007ffff794c4d8 in getpwnam (name=0x501000000060 "repo") at ../nss/getXXbyYY.c:140 #261519 0x00005555557e37ff in getpw_str (username=0x5020000001a1 "repo", len=4) at path.c:613 #261520 0x00005555557e3937 in interpolate_path (path=0x5020000001a0 "~repo", real_home=0) at path.c:654 #261521 0x00005555557e3aea in enter_repo (path=0x501000000040 "~repo", strict=0) at path.c:718 #261522 0x000055555568f0ba in cmd_upload_pack (argc=1, argv=0x502000000100, prefix=0x0, repo=0x0) at builtin/upload-pack.c:57 #261523 0x0000555555575ba8 in run_builtin (p=0x555555a20c98 <commands+3192>, argc=2, argv=0x502000000100, repo=0x555555a53b20 <the_repo>) at git.c:481 #261524 0x0000555555576067 in handle_builtin (args=0x7fffffffaab0) at git.c:742 #261525 0x000055555557678d in cmd_main (argc=2, argv=0x7fffffffac58) at git.c:912 #261526 0x00005555556963cd in main (argc=2, argv=0x7fffffffac58) at common-main.c:64 Note that this stack is more than 260000 function calls deep. Run under the debugger this will eventually segfault, but in our CI systems it seems like this just hangs forever. I assume that this is a bug either in the leak sanitizer or in glibc, as I cannot reproduce it on my machine. In any case, let's work around the bug for now by marking those tests with the "!SANITIZE_LEAK" prereq. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21git-compat-util: drop now-unused `UNLEAK()` macroPatrick Steinhardt2-35/+0
The `UNLEAK()` macro has been introduced with 0e5bba53af (add UNLEAK annotation for reducing leak false positives, 2017-09-08) to help us reduce the amount of reported memory leaks in cases we don't care about, e.g. when exiting immediately afterwards. We have since removed all of its users in favor of freeing the memory and thus don't need the macro anymore. Remove it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21global: drop `UNLEAK()` annotationPatrick Steinhardt2-2/+0
There are two users of `UNLEAK()` left in our codebase: - In "builtin/clone.c", annotating the `repo` variable. That leak has already been fixed though as you can see in the context, where we do know to free `repo_to_free`. - In "builtin/diff.c", to unleak entries of the `blob[]` array. That leak has also been fixed, because the entries we assign to that array come from `rev.pending.objects`, and we do eventually release `rev`. This neatly demonstrates one of the issues with `UNLEAK()`: it is quite easy for the annotation to become stale. A second issue is that its whole intent is to paper over leaks. And while that has been a necessary evil in the past, because Git was leaking left and right, it isn't really much of an issue nowadays where our test suite has no known leaks anymore. Remove the last two users of this macro. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21t/helper: fix leaking commit graph in "read-graph" subcommandPatrick Steinhardt1-2/+1
We're leaking the commit-graph in the "test-helper read-graph" subcommand, but as the leak is annotated with `UNLEAK()` the leak sanitizer doesn't complain. Fix the leak by calling `free_commit_graph()`. Besides getting rid of the `UNLEAK()` annotation, it also increases code coverage because we properly release resources as Git would do it, as well. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21builtin/branch: fix leaking sorting optionsPatrick Steinhardt1-11/+22
The sorting options are leaking, but given that they are marked with `UNLEAK()` the leak sanitizer doesn't complain. Fix the leak by creating a common exit path and clearing the vector such that we can get rid of the `UNLEAK()` annotation entirely. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21builtin/init-db: fix leaking directory pathsPatrick Steinhardt1-15/+19
We've got a couple of leaking directory paths in git-init(1), all of which are marked with `UNLEAK()`. Fixing them is trivial, so let's do that instead so that we can get rid of `UNLEAK()` entirely. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21builtin/help: fix leaks in `check_git_cmd()`Patrick Steinhardt1-6/+7
The `check_git_cmd()` function is declared to return a string constant. And while it sometimes does return a constant, it may also return an allocated string in two cases: - When handling aliases. This case is already marked with `UNLEAK()` to work around the leak. - When handling unknown commands in case "help.autocorrect" is enabled. This one is not marked with `UNLEAK()`. The function only has a single caller, so let's fix its return type to be non-constant, consistently return an allocated string and free it at its callsite to plug the leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21help: fix leaking return value from `help_unknown_cmd()`Patrick Steinhardt3-6/+7
While `help_unknown_cmd()` would usually die on an unknown command, it instead returns an autocorrected command when "help.autocorrect" is set. But while the function is declared to return a string constant, it actually returns an allocated string in that case. Callers thus aren't aware that they have to free the string, leading to a memory leak. Fix the function return type to be non-constant and free the returned value at its only callsite. Note that we cannot simply take ownership of `main_cmds.names[0]->name` and then eventually free it. This is because the `struct cmdname` is using a flex array to allocate the name, so the name pointer points into the middle of the structure and thus cannot be freed. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21help: fix leaking `struct cmdnames`Patrick Steinhardt1-0/+4
We're populating multiple `struct cmdnames`, but don't ever free them. Plug this memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21help: refactor to not use globals for reading configPatrick Steinhardt1-23/+24
We're reading the "help.autocorrect" and "alias.*" configuration into global variables, which makes it hard to manage their lifetime correctly. Refactor the code to use a struct instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21builtin/sparse-checkout: fix leaking sanitized patternsPatrick Steinhardt1-22/+39
Both `git sparse-checkout add` and `git sparse-checkout set` accept a list of additional directories or patterns. These get massaged via calls to `sanitize_paths()`, which may end up modifying the passed-in array by updating its pointers to be prefixed paths. This allocates memory that we never free. Refactor the code to instead use a `struct strvec`, which makes it way easier for us to track the lifetime correctly. The couple of extra memory allocations likely do not matter as we only ever populate it with command line arguments. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21split-index: fix memory leak in `move_cache_to_base_index()`Patrick Steinhardt2-1/+6
In `move_cache_to_base_index()` we move the index cache of the main index into the split index, which is used when writing a shared index. But we don't release the old split index base in case we already had a split index before this operation, which can thus leak memory. Plug the leak by releasing the previous base. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21git: refactor builtin handling to use a `struct strvec`Patrick Steinhardt2-35/+31
Similar as with the preceding commit, `handle_builtin()` does not properly track lifetimes of the `argv` array and its strings. As it may end up modifying the array this can lead to memory leaks in case it contains allocated strings. Refactor the function to use a `struct strvec` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21git: refactor alias handling to use a `struct strvec`Patrick Steinhardt2-26/+33
In `handle_alias()` we use both `argcp` and `argv` as in-out parameters. Callers mostly pass through the static array from `main()`, but once we handle an alias we replace it with an allocated array that may contain some allocated strings. Callers do not handle this scenario at all and thus leak memory. We could in theory handle the lifetime of `argv` in a hacky fashion by letting callers free it in case they see that an alias was handled. But while that would likely work, we still wouldn't be able to easily handle the lifetime of strings referenced by `argv`. Refactor the code to instead use a `struct strvec`, which effectively removes the need for us to manually track lifetimes. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21strvec: introduce new `strvec_splice()` functionPatrick Steinhardt3-0/+93
Introduce a new `strvec_splice()` function that can replace a range of strings in the vector with another array of strings. This function will be used in subsequent commits. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21line-log: fix leak when rewriting commit parentsPatrick Steinhardt2-0/+2
In `process_ranges_merge_commit()` we try to figure out which of the parents can be blamed for the given line changes. When we figure out that none of the files in the line-log have changed we assign the complete blame to that commit and rewrite the parents of the current commit to only use that single parent. This is done via `commit_list_append()`, which is misleadingly _not_ appending to the list of parents. Instead, we overwrite the parents with the blamed parent. This makes us lose track of the old pointers, creating a memory leak. Fix this issue by freeing the parents before we overwrite them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21bisect: fix various cases where we leak commit list itemsPatrick Steinhardt2-8/+23
There are various cases where we leak commit list items because we evict items from the list, but don't free them. Plug those. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21bisect: fix leaking commit list items in `check_merge_base()`Patrick Steinhardt1-2/+2
While we free the result commit list at the end of `check_merge_base()`, we forget to free any items that we have already iterated over. Fix this by using a separate variable to iterate through them. This leak is exposed by t6030, but plugging it does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21bisect: fix multiple leaks in `bisect_next_all()`Patrick Steinhardt1-2/+3
There are multiple leaks in `bisect_next_all()`. For one we don't free the `tried` commit list. Second, one of the branches uses a direct return instead of jumping to the cleanup code. Fix these by freeing the commit list and converting the return to a goto. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21bisect: fix leaking `current_bad_oid`Patrick Steinhardt1-0/+1
When reading bisect refs we read the reference mapping to the "bad" term into the global `current_bad_oid` variable. This is an allocated string, but because it is global we never have to free it. This changes though when `register_ref()` is being called multiple times, at which point we'll overwrite the previous pointer and thus make it unreachable. Fix this issue by freeing the previous value. This leak is exposed by t6030, but plugging it does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21bisect: fix leaking string in `handle_bad_merge_base()`Patrick Steinhardt1-0/+2
When handling a bad merge base we print an error, which includes the set of good revisions joined by spaces. This string is allocated, but never freed. Fix this memory leak. Note that the local `bad_hex` varible also looks like a string that we should free. But in fact, `oid_to_hex()` returns an address to a static variable even though it is declared to return a non-constant string. The function signature is thus quite misleading and really should be fixed, but doing so is outside of the scope of this patch series. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21bisect: fix leaking good/bad terms when reading multipe timesPatrick Steinhardt3-8/+12
Even though `read_bisect_terms()` is declared as assigning string constants, it in fact assigns allocated strings to the `read_bad` and `read_good` out parameters. The only callers of this function assign the result to global variables and thus don't have to free them in order to be leak-free. But that changes when executing the function multiple times because we'd then overwrite the previous value and thus make it unreachable. Fix the function signature and free the previous values. This leak is exposed by t0630, but plugging it does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21builtin/blame: fix leaking blame entries with `--incremental`Patrick Steinhardt4-7/+10
When passing `--incremental` to git-blame(1) we exit early by jumping to the `cleanup` label. But some of the cleanups we perform are handled between the `goto` and its label, and thus we leak the data. Move the cleanups after the `cleanup` label. While at it, move the logic to free the scoreboard's `final_buf` into `cleanup_scoreboard()` and drop its `const` declaration. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-11-21ref: add symlink ref content check for files backendshejialuo4-4/+182
Besides the textual symref, we also allow symbolic links as the symref. So, we should also provide the consistency check as what we have done for textual symref. And also we consider deprecating writing the symbolic links. We first need to access whether symbolic links still be used. So, add a new fsck message "symlinkRef(INFO)" to tell the user be aware of this information. We have already introduced "files_fsck_symref_target". We should reuse this function to handle the symrefs which use legacy symbolic links. We should not check the trailing garbage for symbolic refs. Add a new parameter "symbolic_link" to disable some checks which should only be executed for textual symrefs. And we need to also generate the "referent" parameter for reusing "files_fsck_symref_target" by the following steps: 1. Use "strbuf_add_real_path" to resolve the symlink and get the absolute path "ref_content" which the symlink ref points to. 2. Generate the absolute path "abs_gitdir" of "gitdir" and combine "ref_content" and "abs_gitdir" to extract the relative path "relative_referent_path". 3. If "ref_content" is outside of "gitdir", we just set "referent" with "ref_content". Instead, we set "referent" with "relative_referent_path". Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: shejialuo <shejialuo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>