git/http-push.c, branch v2.51.2

Merge branch 'js/curl-off-t-fixes' into maint-2.51

2025-10-14T20:40:53Z

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

http-push: avoid new compile error

2025-09-26T17:38:18Z

With the recent update in Git for Windows/ARM64 as of https://github.com/git-for-windows/git-sdk-arm64/commit/21b288e16358 cURL was updated from v8.15.0 to v8.16.0, and the LLVM-based builds (but strangely not the GCC-based builds) continuously greet me thusly: http-push.c:211:2: error: call to '_curl_easy_setopt_err_long' declared with 'warning' attribute: curl_easy_setopt expects a long argument [-Werror,-Wattribute-warning] CC builtin/apply.o 211 | curl_easy_setopt(curl, CURLOPT_INFILESIZE, buffer->buf.len); | ^ C:/a/git-sdk-arm64/git-sdk-arm64/minimal-sdk/clangarm64/include/curl/typecheck-gcc.h:50:15: note: expanded from macro 'curl_easy_setopt' 50 | _curl_easy_setopt_err_long(); \ | ^ 1 error generated. make: *** [Makefile:2877: http-push.o] Error 1 The easiest way to shut up that compile error (which is legitimate, seeing as the `CURLOPT_INFILESIZE` options expects a `long` parameter, but `buffer->buf.len` refers to the `size_t` attribute of a `strbuf`) would be to simply cast the parameter to a `long`. However, there is a much better solution: To use the `CURLOPT_INFILESIZE_LARGE` option instead, which was added in cURL v7.11.0 (see https://curl.se/ch/7.11.0.html) and which Git _already_ uses in `curl_append_msgs_to_imap()`. This fix was the motivation for renaming `xcurl_off_t()` to `cast_size_t_to_curl_off_t()` and making it available more broadly, which is the reason why it is used here, too. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'ps/object-store'

2025-07-15T22:18:18Z

Code clean-up around object access API. * ps/object-store: odb: rename `read_object_with_reference()` odb: rename `pretend_object_file()` odb: rename `has_object()` odb: rename `repo_read_object_file()` odb: rename `oid_object_info()` odb: trivial refactorings to get rid of `the_repository` odb: get rid of `the_repository` when handling submodule sources odb: get rid of `the_repository` when handling the primary source odb: get rid of `the_repository` in `for_each()` functions odb: get rid of `the_repository` when handling alternates odb: get rid of `the_repository` in `odb_mkstemp()` odb: get rid of `the_repository` in `assert_oid_type()` odb: get rid of `the_repository` in `find_odb()` odb: introduce parent pointers object-store: rename files to "odb.{c,h}" object-store: rename `object_directory` to `odb_source` object-store: rename `raw_object_store` to `object_database`

odb: rename `has_object()`

2025-07-01T21:46:38Z

Rename `has_object()` to `odb_has_object()` to match other functions related to the object database and our modern coding guidelines. Introduce a compatibility wrapper so that any in-flight topics will continue to compile. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

odb: rename `repo_read_object_file()`

2025-07-01T21:46:38Z

Rename `repo_read_object_file()` to `odb_read_object()` to match other functions related to the object database and our modern coding guidelines. Introduce a compatibility wrapper so that any in-flight topics will continue to compile. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

object-store: rename files to "odb.{c,h}"

2025-07-01T21:46:34Z

In the preceding commits we have renamed the structures contained in "object-store.h" to `struct object_database` and `struct odb_backend`. As such, the code files "object-store.{c,h}" are confusingly named now. Rename them to "odb.{c,h}" accordingly. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

curl: pass `long` values where expected

2025-06-06T15:12:24Z

As of Homebrew's update to cURL v8.14.0, there are new compile errors to be observed in the `osx-gcc` job of Git's CI builds: In file included from http.h:8, from imap-send.c:36: In function 'setup_curl', inlined from 'curl_append_msgs_to_imap' at imap-send.c:1460:9, inlined from 'cmd_main' at imap-send.c:1581:9: /usr/local/Cellar/curl/8.14.0/include/curl/typecheck-gcc.h:50:15: error: call to '_curl_easy_setopt_err_long' declared with attribute warning: curl_easy_setopt expects a long argument [-Werror=attribute-warning] 50 | _curl_easy_setopt_err_long(); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/local/Cellar/curl/8.14.0/include/curl/curl.h:54:7: note: in definition of macro 'CURL_IGNORE_DEPRECATION' 54 | statements \ | ^~~~~~~~~~ imap-send.c:1423:9: note: in expansion of macro 'curl_easy_setopt' 1423 | curl_easy_setopt(curl, CURLOPT_PORT, srvc->port); | ^~~~~~~~~~~~~~~~ [... many more instances of nearly identical warnings...] See for example this CI workflow run: https://github.com/git/git/actions/runs/15454602308/job/43504278284#step:4:307 The most likely explanation is the entry "typecheck-gcc.h: fix the typechecks" in cURL's release notes (https://curl.se/ch/8.14.0.html). Nearly identical compile errors afflicted recently-updated Debian setups, which have been addressed by `jk/curl-easy-setopt-typefix`. However, on macOS Git is built with different build options, which uncovered more instances of `int` values that need to be cast to constants, which were not covered by 6f11c42e8edc (curl: fix integer constant typechecks with curl_easy_setopt(), 2025-06-04). Let's explicitly convert even those remaining `int` constants in `curl_easy_setopt()` calls to `long` parameters. In addition to looking at the compile errors of the `osx-gcc` job, I verified that there are no other instances of the same issue that need to be handled in this manner (and that might not be caught by our CI builds because of yet other build options that might skip those code parts), I ran the following command and inspected all 23 results manually to ensure that the fix is now actually complete: git grep -n curl_easy_setopt | grep -ve ',.*, *[A-Za-z_"&]' \ -e ',.*, *[-0-9]*L)' \ -e ',.*,.* (long)' Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

curl: fix integer constant typechecks with curl_easy_setopt()

2025-06-04T21:17:53Z

The curl documentation specifies that curl_easy_setopt() takes either: ...a long, a function pointer, an object pointer or a curl_off_t, depending on what the specific option expects. But when we pass an integer constant like "0", it will by default be a regular non-long int. This has always been wrong, but seemed to work in practice (I didn't dig into curl's implementation to see whether this might actually be triggering undefined behavior, but it seems likely and regardless we should do what the docs say). This is especially important since curl has a type-checking macro that causes building against curl 8.14 to produce many warnings. The specific commit is due to their 79b4e56b3 (typecheck-gcc.h: fix the typechecks, 2025-04-22). Curiously, it does only seem to trigger when compiled with -O2 for me. We can fix it by just marking the constants with a long "L". Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

treewide: convert users of `repo_has_object_file()` to `has_object()`

2025-04-29T17:08:13Z

As the comment of `repo_has_object_file()` and its `_with_flags()` variant tells us, these functions are considered to be deprecated in favor of `has_object()`. There are a couple of slight benefits in favor of the replacement: - The new function has a short-and-sweet name. - More explicit defaults: `has_object()` doesn't fetch missing objects via promisor remotes, and neither does it reload packfiles if an object wasn't found by default. This ensures that it becomes immediately obvious when a simple object existence check may result in expensive actions. Most importantly though, it is confusing that we have two sets of functions that ultimately do the same thing, but with different defaults. Start sunsetting `repo_has_object_file()` and its `_with_flags()` sibling by replacing all callsites with `has_object()`: - `repo_has_object_file(...)` is equivalent to `has_object(..., HAS_OBJECT_RECHECK_PACKED | HAS_OBJECT_FETCH_PROMISOR)`. - `repo_has_object_file_with_flags(..., OBJECT_INFO_QUICK | OBJECT_INFO_SKIP_FETCH_OBJECT)` is equivalent to `has_object(..., 0)`. - `repo_has_object_file_with_flags(..., OBJECT_INFO_SKIP_FETCH_OBJECT)` is equivalent to `has_object(..., HAS_OBJECT_RECHECK_PACKED)`. - `repo_has_object_file_with_flags(..., OBJECT_INFO_QUICK)` is equivalent to `has_object(..., HAS_OBJECT_FETCH_PROMISOR)`. The replacements should be functionally equivalent. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

object-store: merge "object-store-ll.h" and "object-store.h"

2025-04-15T15:24:37Z

The "object-store-ll.h" header has been introduced to keep transitive header dependendcies and compile times at bay. Now that we have created a new "object-store.c" file though we can easily move the last remaining additional bit of "object-store.h", the `odb_path_map`, out of the header. Do so. As the "object-store.h" header is now equivalent to its low-level alternative we drop the latter and inline it into the former. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano