aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2025-10-14Merge branch 'ps/ci-avoid-broken-sudo-on-ubuntu' into maint-2.51Junio C Hamano1-0/+9
Our CI script requires "sudo" that can be told to preserve environment, but Ubuntu replaced with "sudo" with an implementation that lacks the feature. Work this around by reinstalling the original version. * ps/ci-avoid-broken-sudo-on-ubuntu: ci: fix broken jobs on Ubuntu 25.10 caused by switch to sudo-rs(1)
2025-10-14Merge branch 'jk/curl-global-trace-components' into maint-2.51Junio C Hamano3-1/+18
Adjust to the way newer versions of cURL selectivel enables tracing options, so that our tests can continue to work. * jk/curl-global-trace-components: curl: add support for curl_global_trace() components
2025-10-14Merge branch 'kh/doc-fast-import-markup-fix' into maint-2.51Junio C Hamano1-4/+4
Doc mark-up fix. * kh/doc-fast-import-markup-fix: doc: fast-import: replace literal block with paragraph
2025-10-14Merge branch 'kh/doc-config-typofix' into maint-2.51Junio C Hamano1-1/+1
Documentation typofix. * kh/doc-config-typofix: doc: config: replace backtick with apostrophe for possessive
2025-10-14Merge branch 'kh/doc-interpret-trailers-markup-fix' into maint-2.51Junio C Hamano1-4/+4
Fix missing single-quote pairs in a documentation page. * kh/doc-interpret-trailers-markup-fix: doc: interpret-trailers: close all pairs of single quotes
2025-10-14Merge branch 'ds/doc-count-objects-fix' into maint-2.51Junio C Hamano1-0/+2
Docfix. * ds/doc-count-objects-fix: count-objects: document count-objects pack
2025-10-14Merge branch 'ja/asciidoc-doctor-verbatim-fixes' into maint-2.51Junio C Hamano1-2/+2
Doc mark-up fix. * ja/asciidoc-doctor-verbatim-fixes: doc: fix asciidoc format compatibility in pretty-formats.adoc
2025-10-14Merge branch 'da/cargo-serialize' into maint-2.51Junio C Hamano2-16/+9
Makefile tried to run multiple "cargo build" which would not work very well; serialize their execution to work it around. * da/cargo-serialize: Makefile: build libgit-rs and libgit-sys serially
2025-10-14Merge branch 'js/progress-delay-fix' into maint-2.51Junio C Hamano2-6/+8
The start_delayed_progress() function in the progress eye-candy API did not clear its internal state, making an initial delay value larger than 1 second ineffective, which has been corrected. * js/progress-delay-fix: progress: pay attention to (customized) delay time
2025-10-14Merge branch 'js/curl-off-t-fixes' into maint-2.51Junio C Hamano4-13/+16
A few places where an size_t value was cast to curl_off_t without checking has been updated to use the existing helper function. * js/curl-off-t-fixes: http-push: avoid new compile error imap-send: be more careful when casting to `curl_off_t` http: offer to cast `size_t` to `curl_off_t` safely
2025-10-14Merge branch 'jt/clang-format-foreach-wo-space-before-parenthesis' into ↵Junio C Hamano1-1/+1
maint-2.51 Clang-format update to let our control macros formatted the way we had them traditionally, e.g., "for_each_string_list_item()" without space before the parentheses. * jt/clang-format-foreach-wo-space-before-parenthesis: clang-format: exclude control macros from SpaceBeforeParens
2025-10-14Merge branch 'ds/doc-ggg-pr-fork-clarify' into maint-2.51Junio C Hamano1-4/+7
Update the instruction to use of GGG in the MyFirstContribution document to say that a GitHub PR could be made against `git/git` instead of `gitgitgadget/git`. * ds/doc-ggg-pr-fork-clarify: doc: clarify which remotes can be used with GitGitGadget
2025-10-14Merge branch 'js/doc-gitk-history' into maint-2.51Junio C Hamano1-4/+4
Manual page for "gitk" is updated with the current maintainer's name. * js/doc-gitk-history: doc/gitk: update reference to the external project
2025-10-14Merge branch 'bc/doc-compat-object-format-not-working' into maint-2.51Junio C Hamano1-0/+4
The compatObjectFormat extension is used to hide an incomplete feature that is not yet usable for any purpose other than developing the feature further. Document it as such to discourage its use by mere mortals. * bc/doc-compat-object-format-not-working: docs: note that extensions.compatobjectformat is incomplete
2025-10-14Merge branch 'kh/you-still-use-whatchanged-fix' into maint-2.51Junio C Hamano11-46/+165
The "do you still use it?" message given by a command that is deeply deprecated and allow us to suggest alternatives has been updated. * kh/you-still-use-whatchanged-fix: BreakingChanges: remove claim about whatchanged reports whatchanged: remove not-even-shorter clause whatchanged: hint about git-log(1) and aliasing you-still-use-that??: help the user help themselves t0014: test shadowing of aliases for a sample of builtins git: allow alias-shadowing deprecated builtins git: move seen-alias bookkeeping into handle_alias(...) git: add `deprecated` category to --list-cmds Makefile: don’t add whatchanged after it has been removed
2025-10-14The nineteenth batchJunio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-14Merge branch 'jc/optional-path'Junio C Hamano7-25/+95
Configuration variables that take a pathname as a value (e.g. blame.ignorerevsfile) can be marked as optional by prefixing ":(optoinal)" before its value. * jc/optional-path: parseopt: values of pathname type can be prefixed with :(optional) config: values of pathname type can be prefixed with :(optional) t7500: fix GIT_EDITOR shell snippet t7500: make each piece more independent
2025-10-14Merge branch 'je/doc-push-upstream'Junio C Hamano2-20/+68
Documentation updates. * je/doc-push-upstream: doc: git-push: add explanation of `git push origin main` doc: git-push: clarify "what to push" doc: git-push: clarify "where to push" doc: add an UPSTREAM BRANCHES section to pull/push/fetch doc: git-push: clarify intro
2025-10-14Merge branch 'kh/format-patch-range-diff-notes'Junio C Hamano7-20/+36
"git format-patch --range-diff=... --notes=..." did not drive the underlying range-diff with correct --notes parameter, ending up comparing with different set of notes from its main patch output you would get from "git format-patch --notes=..." for a singleton patch. * kh/format-patch-range-diff-notes: format-patch: handle range-diff on notes correctly for single patches revision: add rdiff_log_arg to rev_info range-diff: rename other_arg to log_arg
2025-10-14Merge branch 'en/xdiff-cleanup'Junio C Hamano9-337/+269
A lot of code clean-up of xdiff. Split out of a larger topic. * en/xdiff-cleanup: xdiff: change type of xdfile_t.changed from char to bool xdiff: add macros DISCARD(0), KEEP(1), INVESTIGATE(2) in xprepare.c xdiff: rename rchg -> changed in xdfile_t xdiff: delete chastore from xdfile_t xdiff: delete fields ha, line, size in xdlclass_t in favor of an xrecord_t xdiff: delete redundant array xdfile_t.ha xdiff: delete struct diffdata_t xdiff: delete local variables that alias fields in xrecord_t xdiff: delete superfluous function xdl_get_rec() in xemit xdiff: delete unnecessary fields from xrecord_t and xdfile_t xdiff: delete local variables and initialize/free xdfile_t directly xdiff: delete static forward declarations in xprepare
2025-10-14Merge branch 'pw/add-p-hunk-splitting-fix'Junio C Hamano2-2/+44
Marking a hunk 'selected' in "git add -p" and then splitting made all the split pieces 'selected'; this has been changed to make them all 'undecided', which gives better end-user experience. * pw/add-p-hunk-splitting-fix: add-patch: update hunk splitability after editing add -p: mark split hunks as undecided
2025-10-14Merge branch 'sj/string-list'Junio C Hamano5-36/+35
The "string-list" API function to find where a given string would be inserted got updated so that it can use unrealistically huge array index that would only fit in size_t but not int or ssize_t to achieve unstated goal. * sj/string-list: refs: enable sign compare warnings check string-list: change "string_list_find_insert_index" return type to "size_t" string-list: replace negative index encoding with "exact_match" parameter string-list: use bool instead of int for "exact_match"
2025-10-14Merge branch 'kh/doc-patch-id-markup-fix'Junio C Hamano1-20/+23
Documentation mark-up fix. * kh/doc-patch-id-markup-fix: doc: patch-id: fix accidental literal blocks
2025-10-14Merge branch 'jn/doc-help-translaing-pretty-options'Junio C Hamano1-5/+6
Documentation for "git log --pretty" options has been updated to make it easier to translate. * jn/doc-help-translaing-pretty-options: doc: do not break sentences into "lego" pieces
2025-10-14Merge branch 'jn/doc-synopsis'Junio C Hamano6-253/+280
Doc-mark-up modernization continues. * jn/doc-synopsis: doc: convert git worktree to synopsis style doc: convert git tag to synopsis style doc: convert git-stash.adoc to synopis style
2025-10-13The eighteenth batchJunio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-13Merge branch 'kn/reftable-consistency-checks'Junio C Hamano16-59/+330
The reftable backend learned to sanity check its on-disk data more carefully. * kn/reftable-consistency-checks: refs/reftable: add fsck check for checking the table name reftable: add code to facilitate consistency checks fsck: order 'fsck_msg_type' alphabetically Documentation/fsck-msgids: remove duplicate msg id reftable: check for trailing newline in 'tables.list' refs: move consistency check msg to generic layer refs: remove unused headers
2025-10-13Merge branch 'ps/commit-graph-per-object-source'Junio C Hamano5-78/+64
Code clean-up around commit-graph. * ps/commit-graph-per-object-source: commit-graph: pass graphs that are to be merged as parameter commit-graph: return commit graph from `repo_find_commit_pos_in_graph()` commit-graph: return the prepared commit graph from `prepare_commit_graph()` revision: drop explicit check for commit graph blame: drop explicit check for commit graph
2025-10-13Merge branch 'ja/doc-markup-attached-paragraph-fix'Junio C Hamano2-15/+17
Documentation mark-up fix. * ja/doc-markup-attached-paragraph-fix: doc: fix indentation of refStorage item in git-config(1) doc: change the markup of paragraphs following a nested list item
2025-10-13Merge branch 'ps/ci-avoid-broken-sudo-on-ubuntu'Junio C Hamano1-0/+9
Our CI script requires "sudo" that can be told to preserve environment, but Ubuntu replaced with "sudo" with an implementation that lacks the feature. Work this around by reinstalling the original version. * ps/ci-avoid-broken-sudo-on-ubuntu: ci: fix broken jobs on Ubuntu 25.10 caused by switch to sudo-rs(1)
2025-10-13builtin/cat-file.c: simplify calling `report_object_status()`Taylor Blau1-1/+1
In b0b910e052 (cat-file.c: add batch handling for submodules, 2025-06-02), we began handling submodule entries specially when batching cat-file like so: $ echo :sha1collisiondetection | git.compile cat-file --batch-check 855827c583bc30645ba427885caa40c5b81764d2 submodule Commit b0b910e052 notes that submodules are handled differently than non-existent objects, which print "<given-name> <type>", since there is (a) no object to resolve the OID of in the first place, and as commit b0b910e052 notes, (b) for submodules in particular, it is useful to know what commit it points at without having to spawn another Git process. That commit does so by calling report_object_status() and passing in "oid_to_hex(&data->oid)" for the "obj_name" parameter. This is unnecessary, however, since report_object_status() will do the same automatically if given a NULL "obj_name" argument. That behavior dates back to 6a951937ae (cat-file: add --batch-all-objects option, 2015-06-22), so rely on that instead of having the caller open-code that part of report_object_status(). Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-11ci: fix broken jobs on Ubuntu 25.10 caused by switch to sudo-rs(1)Patrick Steinhardt1-0/+9
Ubuntu 25.10 has been released. One prominent change in this version of Ubuntu is the switch to some Rust-based utilities. Part of this switch is also that Ubuntu now defaults to sudo-rs(1). Unfortunately, this breaks our CI because sudo-rs(1) does not support the `--preserve-env` flag. Let's revert back to the C-based sudo(1) implementation to fix this. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-10t1016: make sure to use specified GPGJunio C Hamano1-1/+1
c348192a (t1016: clean up style, 2024-10-22) fixed a coding style violation that has an extra space between redirection operator ">" and the redirection target, but at the same time, replaced the use of "git config" to set a configuration variable to be used by the remainder of tests with "test_config". The pattern employed here is that the first set-up test prepares the environment to be used by subsequent tests, which then use the settings left by this set-up test to perform their tasks. Using test_config in the first set-up test means the config setting made by the set-up test is reverted at the end of the first set-up test, which totally misses the point. Go back to use "git config" to fix this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-10The seventeenth batchJunio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-10Merge branch 'en/doc-merge-tree-describe-merge-base'Junio C Hamano1-4/+10
Clarify the "--merge-base" command line option in "git merge-tree". * en/doc-merge-tree-describe-merge-base: Documentation/git-merge-tree.adoc: clarify the --merge-base option
2025-10-10Merge branch 'rj/doc-missing-technical-docs'Junio C Hamano1-0/+8
Doc updates. * rj/doc-missing-technical-docs: doc: add some missing technical documents
2025-10-10Merge branch 'ps/gitlab-ci-windows-improvements'Junio C Hamano2-27/+36
GitLab CI improvements. * ps/gitlab-ci-windows-improvements: t8020: fix test failure due to indeterministic tag sorting gitlab-ci: upload Meson test logs as JUnit reports gitlab-ci: drop workaround for Python certificate store on Windows gitlab-ci: ignore failures to disable realtime monitoring gitlab-ci: dedup instructions to disable realtime monitoring
2025-10-10doc: fix accidental literal blocksKristoffer Haugsbakk5-48/+64
Make sure that normal paragraphs in most user-facing docs[1] don’t use literal blocks. This can easily happen if you try to maintain indentation in order to continue a block; that might work in e.g. Markdown variants, but not in AsciiDoc. The fixes are straightforward, i.e. just deindent the block and maybe add line continuations. The only exception is git-sparse-checkout(1) where we also replace indentation used for *intended* literal blocks with `----`. † 1: These have not been considered: • `Documentation/howto/` • `Documentation/technical/` • `Documentation/gitprotocol*` Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09doc: explain the impact of stash.index on --autostash optionsD. Ben Knoble1-0/+4
With 9842c0c749 (stash: honor stash.index in apply, pop modes, 2025-09-21) merged in a5d4779e6e (Merge branch 'dk/stash-apply-index', 2025-09-29), we did not advertise the connection between the new config option stash.index and the implicit use of git-stash via --autostash (which may also be configured). Do so. Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09t1010: use BROKEN_OBJECTS prerequisitebrian m. carlson1-5/+8
When hash compatibility mode is enabled, we cannot write broken objects because they cannot be mapped into the other hash algorithm. Use the BROKEN_OBJECTS prerequisite to disable these tests and the writing of broken objects in this mode. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09t: allow specifying compatibility hashbrian m. carlson2-2/+20
We want to specify a compatibility hash for testing interactions for SHA-256 repositories where we have SHA-1 compatibility enabled. Allow the user to specify this scenario in the test suite by setting GIT_TEST_DEFAULT_HASH to "sha256:sha1". Note that this will get passed into GIT_DEFAULT_HASH, which Git itself does not presently support. However, we will support this in a future commit. Since we'll now want to know the value for a specific version, let's add the ability to specify either the storage hash (in this case, SHA-256) or the compatibility hash (SHA-1). We use a different value for the compatibility hash that will be enabled for all repositories (test_repo_compat_hash_algo) versus the one that is used individually in some tests (test_compat_hash_algo), since we want to still run those individual tests without requiring that the testsuite be run fully in a compatibility mode. In some cases, we'll need to adjust our test suite to work in a proper way with a compatibility hash. For example, in such a case, we'll only use pack index v3, since v1 and v2 lack support for multiple algorithms. Since we won't want to write those older formats, we'll need to skip tests that do so. Let's add a COMPAT_HASH prerequisite for this purpose. Finally, in this scenario, we can no longer rely on having broken objects work since we lack compatibility mappings to rewrite objects in the repository. Add a prerequisite, BROKEN_OBJECTS, that we define in terms of COMPAT_HASH and checks to see if creating deliberately broken objects is possible, so that we can disable these tests if not. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09fsck: consider gpgsig headers expected in tagsbrian m. carlson4-0/+80
When we're creating a tag, we want to make sure that gpgsig and gpgsig-sha256 headers are allowed for the commit. The default fsck behavior is to ignore the fact that they're left over, but some of our tests enable strict checking which flags them nonetheless. Add improved checking for these headers as well as documentation and several tests. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09rev-parse: allow printing compatibility hashbrian m. carlson3-6/+50
Right now, we have a way to print the storage hash, the input hash, and the output hash, but we lack a way to print the compatibility hash. Add a new type to --show-object-format, compat, which prints this value. If no compatibility hash exists, simply print a newline. This is important to allow users to use multiple options at once while still getting unambiguous output. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09docs: add documentation for loose objectsbrian m. carlson3-0/+55
We currently have no documentation for how loose objects are stored. Let's add some here so it's easy for people to understand how they work. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09docs: improve ambiguous areas of pack format documentationbrian m. carlson1-0/+19
It is fair to say that our pack and indexing code is quite complex. Contributors who wish to work on this code or implementors of other implementations would benefit from clear, unambiguous documentation about how our data formats are structured and encoded and what data is used in the computation of certain values. Unfortunately, some of this data is missing, which leads to confusion and frustration. Let's document some of this data to help clarify things. Specify over what data CRC32 values are computed and also note which CRC32 algorithm is used, since Wikipedia mentions at least four 32-bit CRC algorithms and notes that it's possible to use different bit orderings. In addition, note how we encode objects in the pack. One might be led to believe that packed objects are always stored with the "<type> <size>\0" prefix of loose objects, but that is not the case, although for obvious reasons this data is included in the computation of the object ID. Explain why this is for the curious reader. Finally, indicate what the size field of the packed object represents. Otherwise, a reader might think that the size of a delta is the size of the full object or that it might contain the offset or object ID, neither of which are the case. Explain clearly, however, that the values represent uncompressed sizes to avoid confusion. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09docs: reflect actual double signature for tagsbrian m. carlson1-11/+13
The documentation for the hash function transition reflects the original design where the SHA-256 signature would always be placed in a header. However, due to a missed patch in Git 2.29, we shipped SHA-256 support such that the signature for the current algorithm is always an in-body signature and the opposite algorithm is always in a header. Since the documentation is inaccurate, update it to reflect the correct information. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09docs: update offset order for pack index v3brian m. carlson1-6/+4
The current design of pack index v3 has items in two different orders: sorted shortened object ID order and pack order. The shortened object IDs and the pack index offset values are in the former order and everything else is in the latter. This, however, poses some problems. We have many parts of the packfile code that expect to find out data about an object knowing only its index in pack order. With the current design, to find the pack offset after having looked up the index in pack order, we must then look up the full object ID and use that to look up the shortened object ID to find the pack offset, which is inconvenient, inefficient, and leads to poor cache usage. Instead, let's change the offset values to be looked up by pack order. This works better because once we know the pack order offset, we can find the full object name and its location in the pack with a simple index into their respective tables. This makes many operations much more efficient, especially with the functions we already have, and it avoids the need for the revindex with pack index v3. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09docs: update pack index v3 formatbrian m. carlson1-4/+8
Our current pack index v3 format uses 4-byte integers to find the trailer of the file. This effectively means that the file cannot be much larger than 2^32. While this might at first seem to be okay, we expect that each object will have at least 64 bytes worth of data, which means that no more than about 67 million objects can be stored. Again, this might seem fine, but unfortunately, we know of many users who attempt to create repos with extremely large numbers of commits to get a "high score," and we've already seen repositories with at least 55 million commits. In the interests of gracefully handling repositories even for these well-intentioned but ultimately misguided users, let's change these lengths to 8 bytes. For the checksums at the end of the file, we're producing 32-byte SHA-256 checksums because that's what we already do with pack index v2 and SHA-256. Truncating SHA-256 doesn't pose any actual security problems other than those related to the reduced size, but our pack checksum must already be 32 bytes (since SHA-256 packs have 32-byte checksums) and it simplifies the code to use the existing hashfile logic for these cases for the index checksum as well. In addition, even though we may not need cryptographic security for the index checksum, we'd like to avoid arguments from auditors and such for organizations that may have compliance or security requirements. Using the simple, boring choice of the full SHA-256 hash avoids all possible discussion related to hash truncation and removes impediments for these organizations. Note that we do not yet have a pack index v3 implementation in Git, so it should be fine to change this format. However, such an implementation has been written for future inclusion following this format. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09refs: forbid clang to complain about unreachable codeJohannes Schindelin1-1/+7
When `NO_SYMLINK_HEAD` is defined, `create_ref_symlink()` is hard-coded as `(-1)`, and as a consequence the condition `!create_ref_symlink()` always evaluates to false, rendering any code guarded by that condition unreachable. Therefore, clang is _technically_ correct when it complains about unreachable code. It does completely miss the fact that this is okay because on _other_ platforms, where `NO_SYMLINK_HEAD` is not defined, the code isn't unreachable at all. Let's use the same trick as in 82e79c63642c (git-compat-util: add NOT_CONSTANT macro and use it in atfork_prepare(), 2025-03-17) to appease clang while at the same time keeping the `-Wunreachable` flag to potentially find _actually_ unreachable code. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-10-09mingw: order `#include`s alphabeticallyJohannes Schindelin1-11/+11
It allows for more consistent patches that way. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>