summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-06-23remote: remove branch->merge_name and fix branch_release()Jacob Keller4-21/+33
The branch structure has both branch->merge_name and branch->merge for tracking the merge information. The former is allocated by add_merge() and stores the names read from the configuration file. The latter is allocated by set_merge() which is called by branch_get() when an external caller requests a branch. This leads to the confusing situation where branch->merge_nr tracks both the size of branch->merge (once its allocated) and branch->merge_name. The branch_release() function incorrectly assumes that branch->merge is always set when branch->merge_nr is non-zero, and can potentially crash if read_config() is called without branch_get() being called on every branch. In addition, branch_release() fails to free some of the memory associated with the structure including: * Failure to free the refspec_item containers in branch->merge[i] * Failure to free the strings in branch->merge_name[i] * Failure to free the branch->merge_name parent array. The set_merge() function sets branch->merge_nr to 0 when there is no valid remote_name, to avoid external callers seeing a non-zero merge_nr but a NULL merge array. This results in failure to release most of the merge data as well. These issues could be fixed directly, and indeed I initially proposed such a change at [1] in the past. While this works, there was some confusion during review because of the inconsistencies. Instead, its time to clean up the situation properly. Remove branch->merge_name entirely. Instead, allocate branch->merge earlier within add_merge() instead of within set_merge(). Instead of having set_merge() copy from merge_name[i] to merge[i]->src, just have add_merge() directly initialize merge[i]->src. Modify the add_merge() to call xstrdup() itself, instead of having the caller of add_merge() do so. This makes it more obvious which code owns the memory. Update all callers which use branch->merge_name[i] to use branch->merge[i]->src instead. Add a merge_clear() function which properly releases all of the merge-related memory, and which sets branch->merge_nr to zero. Use this both in branch_release() and in set_merge(), fixing the leak when set_merge() finds no valid remote_name. Add a set_merge variable to the branch structure, which indicates whether set_merge() has been called. This replaces the previous use of a NULL check against the branch->merge array. With these changes, the merge array is always allocated when merge_nr is non-zero. This use of refspec_item to store the names should be safe. External callers should be using branch_get() to obtain a pointer to the branch, which will call set_merge(), and the callers internal to remote.c already handle the partially initialized refpsec_item structure safely. This end result is cleaner, and avoids duplicating the merge names twice. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Link: [1] https://lore.kernel.org/git/20250617-jk-submodule-helper-use-url-v2-1-04cbb003177d@gmail.com/ Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23repack: exclude cruft pack(s) from the MIDX where possibleTaylor Blau3-20/+319
In ddee3703b3 (builtin/repack.c: add cruft packs to MIDX during geometric repack, 2022-05-20), repack began adding cruft pack(s) to the MIDX with '--write-midx' to ensure that the resulting MIDX was always closed under reachability in order to generate reachability bitmaps. While the previous patch added the '--stdin-packs=follow' option to pack-objects, it is not yet on by default. Given that, suppose you have a once-unreachable object packed in a cruft pack, which later becomes reachable from one or more objects in a geometrically repacked pack. That once-unreachable object *won't* appear in the new pack, since the cruft pack was not specified as included or excluded when the geometrically repacked pack was created with 'pack-objects --stdin-packs' (*not* '--stdin-packs=follow', which is not on). If that new pack is included in a MIDX without the cruft pack, then trying to generate bitmaps for that MIDX may fail. This happens when the bitmap selection process picks one or more commits which reach the once-unreachable objects. To mitigate this failure mode, commit ddee3703b3 ensures that the MIDX will be closed under reachability by including cruft pack(s). If cruft pack(s) were not included, we would fail to generate a MIDX bitmap. But ddee3703b3 alludes to the fact that this is sub-optimal by saying [...] it's desirable to avoid including cruft packs in the MIDX because it causes the MIDX to store a bunch of objects which are likely to get thrown away. , which is true, but hides an even larger problem. If repositories rarely prune their unreachable objects and/or have many of them, the MIDX must keep track of a large number of objects which bloats the MIDX and slows down object lookup. This is doubly unfortunate because the vast majority of objects in cruft pack(s) are unlikely to be read. But any object lookups that go through the MIDX must binary search over them anyway, slowing down object lookups using the MIDX. This patch causes geometrically-repacked packs to contain a copy of any once-unreachable object(s) with 'git pack-objects --stdin-packs=follow', allowing us to avoid including any cruft packs in the MIDX. This is because a sequence of geometrically-repacked packs that were all generated with '--stdin-packs=follow' are guaranteed to have their union be closed under reachability. Note that you cannot guarantee that a collection of packs is closed under reachability if not all of them were generated with "following" as above. One tell-tale sign that not all geometrically-repacked packs in the MIDX were generated with "following" is to see if there is a pack in the existing MIDX that is not going to be somehow represented (either verbatim or as part of a geometric rollup) in the new MIDX. If there is, then starting to generate packs with "following" during geometric repacking won't work, since it's open to the same race as described above. But if you're starting from scratch (e.g., building the first MIDX after an all-into-one '--cruft' repack), then you can guarantee that the union of subsequently generated packs from geometric repacking *is* closed under reachability. (One exception here is when "starting from scratch" results in a noop repack, e.g., because the non-cruft pack(s) in a repository already form a geometric progression. Since we can't tell whether or not those were generated with '--stdin-packs=follow', they may depend on once-unreachable objects, so we have to include the cruft pack in the MIDX in this case.) Detect when this is the case and avoid including cruft packs in the MIDX where possible. The existing behavior remains the default, and the new behavior is available with the config 'repack.midxMustIncludeCruft' set to 'false'. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: introduce '--stdin-packs=follow'Taylor Blau3-23/+193
When invoked with '--stdin-packs', pack-objects will generate a pack which contains the objects found in the "included" packs, less any objects from "excluded" packs. Packs that exist in the repository but weren't specified as either included or excluded are in practice treated like the latter, at least in the sense that pack-objects won't include objects from those packs. This behavior forces us to include any cruft pack(s) in a repository's multi-pack index for the reasons described in ddee3703b3 (builtin/repack.c: add cruft packs to MIDX during geometric repack, 2022-05-20). The full details are in ddee3703b3, but the gist is if you have a once-unreachable object in a cruft pack which later becomes reachable via one or more commits in a pack generated with '--stdin-packs', you *have* to include that object in the MIDX via the copy in the cruft pack, otherwise we cannot generate reachability bitmaps for any commits which reach that object. Note that the traversal here is best-effort, similar to the existing traversal which provides name-hash hints. This means that the object traversal may hand us back a blob that does not actually exist. We *won't* see missing trees/commits with 'ignore_missing_links' because: - missing commit parents are discarded at the commit traversal stage by revision.c::process_parents() - missing tag objects are discarded by revision.c::handle_commit() - missing tree objects are discarded by the list-objects code in list-objects.c::process_tree() But we have to handle potentially-missing blobs specially by making a separate check to ensure they exist in the repository. Failing to do so would mean that we'd add an object to the packing list which doesn't actually exist, rendering us unable to write out the pack. This prepares us for new repacking behavior which will "resurrect" objects found in cruft or otherwise unspecified packs when generating new packs. In the context of geometric repacking, this may be used to maintain a sequence of geometrically-repacked packs, the union of which is closed under reachability, even in the case described earlier. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: swap 'show_{object,commit}_pack_hint'Taylor Blau1-6/+6
show_commit_pack_hint() has heretofore been a noop, so its position within its compilation unit only needs to appear before its first use. But the following commit will sometimes have `show_commit_pack_hint()` call `show_object_pack_hint()`, so reorder the former to appear after the latter to minimize the code movement in that patch. Suggested-by: Elijah Newren <newren@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: fix typo in 'show_object_pack_hint()'Taylor Blau1-1/+1
Noticed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: perform name-hash traversal for unpacked objectsTaylor Blau1-8/+12
With '--unpacked', pack-objects adds loose objects (which don't appear in any of the excluded packs from '--stdin-packs') to the output pack without considering them as reachability tips for the name-hash traversal. This was an oversight in the original implementation of '--stdin-packs', since the code which enumerates and adds loose objects to the output pack (`add_unreachable_loose_objects()`) did not have access to the 'rev_info' struct found in `read_packs_list_from_stdin()`. Excluding unpacked objects from that traversal doesn't affect the correctness of the resulting pack, but it does make it harder to discover good deltas for loose objects. Now that the 'rev_info' struct is declared outside of `read_packs_list_from_stdin()`, we can pass it to `add_objects_in_unpacked_packs()` and add any loose objects as tips to the above-mentioned traversal, in theory producing slightly tighter packs as a result. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: declare 'rev_info' for '--stdin-packs' earlierTaylor Blau1-33/+34
Once 'read_packs_list_from_stdin()' has called for_each_object_in_pack() on each of the input packs, we do a reachability traversal to discover names for any objects we picked up so we can generate name hash values and hopefully get higher quality deltas as a result. A future commit will change the purpose of this reachability traversal to find and pack objects which are reachable from commits in the input packs, but are packed in an unknown (not included nor excluded) pack. Extract the code which initializes and performs the reachability traversal to take place in the caller, not the callee, which prepares us to share this code for the '--unpacked' case (see the function add_unreachable_loose_objects() for more details). Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: factor out handling '--stdin-packs'Taylor Blau1-6/+12
At the bottom of cmd_pack_objects() we check which mode the command is running in (e.g., generating a cruft pack, handling '--stdin-packs', using the internal rev-list, etc.) and handle the mode appropriately. The '--stdin-packs' case is handled inline (dating back to its introduction in 339bce27f4 (builtin/pack-objects.c: add '--stdin-packs' option, 2021-02-22)) since it is relatively short. Extract the body of "if (stdin_packs)" into its own function to prepare for the implementation to become lengthier in a following commit. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: limit scope in 'add_object_entry_from_pack()'Taylor Blau1-1/+1
In add_object_entry_from_pack() we declare 'revs' (given to us through the miscellaneous context argument) earlier in the "if (p)" conditional than is necessary. Move it down as far as it can go to reduce its scope. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23pack-objects: use standard option incompatibility functionsTaylor Blau2-10/+12
pack-objects has a handful of explicit checks for pairs of command-line options which are mutually incompatible. Many of these pre-date a699367bb8 (i18n: factorize more 'incompatible options' messages, 2022-01-31). Convert the explicit checks into die_for_incompatible_opt2() calls, which simplifies the implementation and standardizes pack-objects' output when given incompatible options (e.g., --stdin-packs with --filter gives different output than --keep-unreachable with --unpack-unreachable). There is one minor piece of test fallout in t5331 that expects the old format, which has been corrected. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23t7422: replace confusing printf with echoJeff King1-1/+2
While looping over a counter "i", we do: printf "[submodule \"sm-$i\"]\npath = recursive-submodule-path-$i\n" "$i" So we are passing "$i" as an argument to be filled in, but there is no "%" placeholder in the format string, which is a bit confusing to read. We could switch both instances of "$i" to "%d" (and pass $i twice). But that makes the line even longer. Let's just keep interpolating the value in the string, and drop the confusing extra "$i" argument. And since we are not using any printf specifiers at all, it becomes clear that we can swap it out for echo. We do use a "\n" in the middle of the string, but breaking this into two separate echo statements actually makes it easier to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-23coccicheck: fail "make" when it failsJunio C Hamano1-2/+5
With "make coccicheck", we generate contrib/coccinelle/*.cocci.patch files that contain changes suggested by semantic patches, but "make" succeeds. Admittedly, not many developers may run "make coccicheck" in the first place, but it makes it harder to notice when they do run it after they introduced an iffy piece of code. Check that the resulting cocci.patch files are all empty. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-21Merge branch 'ob/strip-comments-on-commit'Johannes Sixt1-4/+2
* ob/strip-comments-on-commit: git-gui: do not end the commit message with an empty line
2025-06-20cocci: matching (multiple) identifiersJunio C Hamano1-1/+2
"make coccicheck" seems to work OK at GitHub CI using $ spatch --version spatch version 1.1.1 compiled with OCaml version 4.13.1 OCaml scripting support: yes Python scripting support: yes Syntax of regular expressions: PCRE but not with $ spatch --version spatch version 1.3 compiled with OCaml version 5.3.0 OCaml scripting support: yes Python scripting support: yes Syntax of regular expressions: Str Judging from https://ocaml.org/manual/5.3/api/Str.html, I suspect that this probably is caused by the distinction between BRE vs PCRE. As there is no reasonably clean way to write the multiple choice matches portably between these two pattern languages, let's stop using regexp_constraint and use compare_constraint instead when listing the function names to exclude. There are other uses of "!~" but they all want to match a single simple token, that should work fine either with BRE or PCRE. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: improve error messages with configuration hintsJörg Thalheim1-2/+7
Replace basic error messages with more helpful ones that guide users on how to resolve configuration issues. When imap.host or imap.folder are missing, provide the exact git config commands needed to fix the problem, along with examples of typical values. Use the advise() API to display hints in a multi-line format with proper "hint:" prefixes for each line. Signed-off-by: Jörg Thalheim <joerg@thalheim.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: fix confusing 'store' terminology in error messageJörg Thalheim1-1/+1
The error message 'no imap store specified' is misleading because it refers to 'store' when the actual missing configuration is 'imap.folder'. Update the message to use the correct terminology that matches the configuration variable name. This reduces confusion for users who might otherwise look for non-existent 'imap.store' configuration when they see this error. Signed-off-by: Jörg Thalheim <joerg@thalheim.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20Merge branch 'ag/imap-send-resurrection' into jt/imap-send-message-fixJunio C Hamano3-77/+407
* ag/imap-send-resurrection: imap-send: fix minor mistakes in the logs imap-send: display the destination mailbox when sending a message imap-send: display port alongwith host when git credential is invoked imap-send: add ability to list the available folders imap-send: enable specifying the folder using the command line imap-send: add PLAIN authentication method to OpenSSL imap-send: add support for OAuth2.0 authentication imap-send: gracefully fail if CRAM-MD5 authentication is requested without OpenSSL imap-send: fix memory leak in case auth_cram_md5 fails imap-send: fix bug causing cfg->folder being set to NULL
2025-06-20imap-send: fix minor mistakes in the logsAditya Garg1-12/+12
Some minor mistakes have been found in the logs. Most of them include error messages starting with a capital letter, and ending with a period. Abbreviations like "IMAP" and "OK" should also be in uppercase. Another mistake was that the error message showing unknown authentication mechanism used was displaying the host rather than the mechanism in the logs. Fix them. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: display the destination mailbox when sending a messageAditya Garg1-2/+4
Whenever we sent a message using the `imap-send` command, it would display a log showing the number of messages which are to be sent. For example: sending 1 message 100% (1/1) done This had been made more informative by adding the name of the destination folder as well: Sending 1 message to Drafts folder... 100% (1/1) done Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: display port alongwith host when git credential is invokedAditya Garg1-1/+1
When requesting for passsword, git credential helper used to display only the host name. For example: Password for 'imaps://gargaditya08%40live.com@outlook.office365.com': Now, it will display the port along with the host name: Password for 'imaps://gargaditya08%40live.com@outlook.office365.com:993': This has been done to make credential helpers more specific for ports. Also, this behaviour will also mimic git send-email, which displays the port along with the host name when requesting for a password. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: add ability to list the available foldersAditya Garg2-17/+87
Various IMAP servers have different ways to name common folders. For example, the folder where all deleted messages are stored is often named "[Gmail]/Trash" on Gmail servers, and "Deleted" on Outlook. Similarly, the Drafts folder is simply named "Drafts" on Outlook, but on Gmail it is named "[Gmail]/Drafts". This commit adds a `--list` command to the `imap-send` tool that lists the available folders on the IMAP server, allowing users to see which folders are available and how they are named. A sample output looks like this when run against a Gmail server: Fetching the list of available folders... * LIST (\HasNoChildren) "/" "INBOX" * LIST (\HasChildren \Noselect) "/" "[Gmail]" * LIST (\All \HasNoChildren) "/" "[Gmail]/All Mail" * LIST (\Drafts \HasNoChildren) "/" "[Gmail]/Drafts" * LIST (\HasNoChildren \Important) "/" "[Gmail]/Important" * LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail" * LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam" * LIST (\Flagged \HasNoChildren) "/" "[Gmail]/Starred" * LIST (\HasNoChildren \Trash) "/" "[Gmail]/Trash" For OpenSSL, this is achived by running the 'IMAP LIST' command and parsing the response. This command is specified in RFC6154: https://datatracker.ietf.org/doc/html/rfc6154#section-5.1 For libcurl, the example code published in the libcurl documentation is used to implement this functionality: https://curl.se/libcurl/c/imap-list.html Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: enable specifying the folder using the command lineAditya Garg3-7/+23
Some users may very often want to imap-send messages to a folder other than the default set in the config. Add a command line argument for the same. While at it, fix minor mark-up inconsistencies in the existing documentation text. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: add PLAIN authentication method to OpenSSLAditya Garg2-3/+61
The current implementation for PLAIN in imap-send works just fine if using curl, but if attempted to use for OpenSSL, it is treated as an invalid mechanism. The default implementation for OpenSSL is IMAP LOGIN command rather than AUTH PLAIN. Since AUTH PLAIN is still used today by many email providers in form of app passwords, lets add an implementation that can use AUTH PLAIN if specified. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: add support for OAuth2.0 authenticationAditya Garg3-13/+183
OAuth2.0 is a new way of authentication supported by various email providers these days. OAUTHBEARER and XOAUTH2 are the two most common mechanisms used for OAuth2.0. OAUTHBEARER is described in RFC5801[1] and RFC7628[2], whereas XOAUTH2 is Google's proprietary mechanism (See [3]). [1]: https://datatracker.ietf.org/doc/html/rfc5801 [2]: https://datatracker.ietf.org/doc/html/rfc7628 [3]: https://developers.google.com/workspace/gmail/imap/xoauth2-protocol#initial_client_response Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: gracefully fail if CRAM-MD5 authentication is requested without ↵Aditya Garg1-27/+39
OpenSSL Unlike PLAIN, XOAUTH2 and OAUTHBEARER, CRAM-MD5 authentication is not supported by libcurl and requires OpenSSL. If the user tries to use CRAM-MD5 authentication without OpenSSL, the previous behaviour was to attempt to authenticate and fail with a die(error). Handle this in a better way by first checking if OpenSSL is available and then attempting to authenticate. If OpenSSL is not available, print an error message and exit gracefully. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: fix memory leak in case auth_cram_md5 failsAditya Garg1-1/+3
This patch fixes a memory leak by running free(response) in case auth_cram_md5 fails. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-20imap-send: fix bug causing cfg->folder being set to NULLAditya Garg1-4/+4
6d1f198f34 (imap-send: fix leaking memory in `imap_server_conf`, 2024-06-07) resulted a change in static int git_imap_config which resulted in cfg->folder being incorrectly set to NULL in case imap.user, imap.pass, imap.tunnel and imap.authmethod were defined. Because of this, since Git 2.46.0, git-imap-send is not usable at all. The bug seems to have been unnoticed for a long time, likely due to better options like git-send-email. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-19git-gui i18n: Updated Bulgarian translation (578t)Alexander Shopov1-1576/+1542
Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2025-06-18The second batchJunio C Hamano1-3/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-18Merge branch 'rj/meson-tap-parse-fixup'Junio C Hamano1-0/+3
An earlier test update incorrectly lost three prerequisites on macOS, which has been corrected. * rj/meson-tap-parse-fixup: test-lib: add missing prerequisites for Darwin
2025-06-18Merge branch 'ly/submodule-update-failure-leakfix'Junio C Hamano1-1/+3
A memory leak on an error code path has been plugged. * ly/submodule-update-failure-leakfix: builtin/submodule--helper: fix leak when remote_submodule_branch() failed
2025-06-18Merge branch 'jm/bundle-uri-debug-output-to-fp'Junio C Hamano1-1/+1
Code clean-up. * jm/bundle-uri-debug-output-to-fp: bundle-uri: send debug output to given FILE * stream
2025-06-18Merge branch 'bs/solaris-10-and-11'Junio C Hamano1-3/+25
Add settings for Solaris 10 & 11. * bs/solaris-10-and-11: config.mak.uname: update settings for Solaris 10 and 11
2025-06-18Merge branch 'jw/doc-txt-to-adoc-refs'Junio C Hamano5-7/+10
Some leftover references to documentation source files that no longer exist, due to recent ".txt" -> ".adoc" renaming, have been corrected. * jw/doc-txt-to-adoc-refs: doc: update references to renamed AsciiDoc files
2025-06-18Merge branch 'ma/doc-diff-cc-headers'Junio C Hamano1-1/+1
Doc mark-up update. * ma/doc-diff-cc-headers: diff-generate-patch.adoc: drop spurious backticks
2025-06-18Merge branch 'ly/pack-bitmap-root-leakfix'Junio C Hamano2-2/+19
Memleak fix on an error code path. * ly/pack-bitmap-root-leakfix: pack-bitmap: remove checks before bitmap_free
2025-06-18Merge branch 'ly/commit-buffer-reencode-leakfix'Junio C Hamano2-1/+3
Leakfix. * ly/commit-buffer-reencode-leakfix: repo_logmsg_reencode: fix memory leak when use repo_logmsg_reencode ()
2025-06-18Merge branch 'cf/guideline-documenting-config-vars'Junio C Hamano1-0/+11
CodingGuidelines update. * cf/guideline-documenting-config-vars: CodingGuidelines: document formatting of similar config variables.
2025-06-18CodingGuidelines: document formatting of similar config variables.Collin Funk1-0/+11
Document that related `git config` variables should be placed one-per-line instead of separated by commas. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Collin Funk <collin.funk1@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-18diff-no-index: do not reference .d_type member of struct direntJunio C Hamano1-1/+13
Some platforms like AIX lack .d_type member in "struct dirent"; use the DTYPE(e) macro instead of a direct reference to e->d_type and when it yields DT_UNKNOWN, find the real type with get_dtype(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-17Start 2.51 cycle, the first batchJunio C Hamano3-2/+47
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-06-17Merge branch 'ps/meson-tap-parse'Junio C Hamano19-117/+133
Meson-based build/test framework now understands TAP output generated by our tests. * ps/meson-tap-parse: meson: parse TAP output generated by our tests meson: introduce kwargs variable for tests test-lib: fail on unexpectedly passing tests t7815: fix unexpectedly passing test on macOS t/test-lib: fix TAP format for BASH_XTRACEFD warning t/test-lib: don't print shell traces to stdout t983*: use prereq to check for Python-specific git-p4(1) support t9822: use prereq to check for ISO-8859-1 support t: silence output from `test_create_repo()` t: stop announcing prereqs
2025-06-17Merge branch 'jk/diff-no-index-with-pathspec'Junio C Hamano7-24/+182
"git diff --no-index dirA dirB" can limit the comparison with pathspec at the end of the command line, just like normal "git diff". * jk/diff-no-index-with-pathspec: diff --no-index: support limiting by pathspec pathspec: add flag to indicate operation without repository pathspec: add match_leading_pathspec variant
2025-06-17Merge branch 'ly/fetch-pack-leakfix'Junio C Hamano1-2/+5
A memory-leak in an error code path has been plugged. * ly/fetch-pack-leakfix: builtin/fetch-pack: cleanup before return error
2025-06-17Merge branch 'ly/commit-graph-graph-write-leakfix'Junio C Hamano1-0/+1
A memory-leak in an error code path has been plugged. * ly/commit-graph-graph-write-leakfix: commit-graph: fix start_delayed_progress() leak
2025-06-17Merge branch 'ly/do-not-localize-bug-messages'Junio C Hamano3-3/+3
Code clean-up. * ly/do-not-localize-bug-messages: BUG(): remove leading underscore of the format string
2025-06-17Merge branch 'ly/sequencer-update-squash-is-fixup-only'Junio C Hamano1-2/+4
Code clean-up. * ly/sequencer-update-squash-is-fixup-only: sequencer: replace error() with BUG() in update_squash_messages ()
2025-06-17Merge branch 'vd/cat-file-objectmode-update'Junio C Hamano3-34/+102
"git cat-file --batch" learns to understand %(objectmode) atom to allow the caller to tell missing objects (due to repository corruption) and submodules (whose commit objects are OK to be missing) apart. * vd/cat-file-objectmode-update: cat-file.c: add batch handling for submodules cat-file: add %(objectmode) atom t1006: update 'run_tests' to test generic object specifiers
2025-06-17Merge branch 'ag/send-email-docs'Junio C Hamano3-134/+147
Documentation for "git send-email" has been updated with a bit more credential helper and OAuth information. * ag/send-email-docs: docs: make the purpose of using app password for Gmail more clear in send-email docs: remove credential helper links for emails from gitcredentials docs: improve formatting in git-send-email documentation docs: add credential helper for yahoo and link Google's sendgmail tool
2025-06-17Merge branch 'rc/userdiff-r'Junio C Hamano4-0/+26
Userdiff patterns for the R language. * rc/userdiff-r: userdiff: add support for R programming language