git/remote.c, branch v2.48.2

Merge branch 'sk/calloc-not-malloc-plus-memset'

2024-12-23T17:32:18Z

Code clean-up. * sk/calloc-not-malloc-plus-memset: git: use calloc instead of malloc + memset where possible

Merge branch 'ps/build-sign-compare'

2024-12-23T17:32:11Z

Start working to make the codebase buildable with -Wsign-compare. * ps/build-sign-compare: t/helper: don't depend on implicit wraparound scalar: address -Wsign-compare warnings builtin/patch-id: fix type of `get_one_patchid()` builtin/blame: fix type of `length` variable when emitting object ID gpg-interface: address -Wsign-comparison warnings daemon: fix type of `max_connections` daemon: fix loops that have mismatching integer types global: trivial conversions to fix `-Wsign-compare` warnings pkt-line: fix -Wsign-compare warning on 32 bit platform csum-file: fix -Wsign-compare warning on 32-bit platform diff.h: fix index used to loop through unsigned integer config.mak.dev: drop `-Wno-sign-compare` global: mark code units that generate warnings with `-Wsign-compare` compat/win32: fix -Wsign-compare warning in "wWinMain()" compat/regex: explicitly ignore "-Wsign-compare" warnings git-compat-util: introduce macros to disable "-Wsign-compare" warnings

git: use calloc instead of malloc + memset where possible

2024-12-18T18:48:34Z

Avoid calling malloc + memset by calling calloc. Signed-off-by: Seija Kijin Signed-off-by: Junio C Hamano

global: mark code units that generate warnings with `-Wsign-compare`

2024-12-06T11:20:02Z

Mark code units that generate warnings with `-Wsign-compare`. This allows for a structured approach to get rid of all such warnings over time in a way that can be easily measured. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

fetch set_head: add warn-if-not-$branch option

2024-12-05T17:59:40Z

Currently if we want to have a remote/HEAD locally that is different from the one on the remote, but we still want to get a warning if remote changes HEAD, our only option is to have an indiscriminate warning with "follow_remote_head" set to "warn". Add a new option "warn-if-not-$branch", where $branch is a branch name we do not wish to get a warning about. If the remote HEAD is $branch do not warn, otherwise, behave as "warn". E.g. let's assume, that our remote origin has HEAD set to "master", but locally we have "git remote set-head origin seen". Setting 'remote.origin.followRemoteHEAD = "warn"' will always print a warning, even though the remote has not changed HEAD from "master". Setting 'remote.origin.followRemoteHEAD = "warn-if-not-master" will squelch the warning message, unless the remote changes HEAD from "master". Note, that should the remote change HEAD to "seen" (which we have locally), there will still be no warning. Improve the advice message in report_set_head to also include silencing the warning message with "warn-if-not-$branch". Signed-off-by: Bence Ferdinandy Signed-off-by: Junio C Hamano

fetch: add configuration for set_head behaviour

2024-12-02T00:55:17Z

In the current implementation, if refs/remotes/$remote/HEAD does not exist, running fetch will create it, but if it does exist it will not do anything, which is a somewhat safe and minimal approach. Unfortunately, for users who wish to NOT have refs/remotes/$remote/HEAD set for any reason (e.g. so that `git rev-parse origin` doesn't accidentally point them somewhere they do not want to), there is no way to remove this behaviour. On the other side of the spectrum, users may want fetch to automatically update HEAD or at least give them a warning if something changed on the remote. Introduce a new setting, remote.$remote.followRemoteHEAD with four options: - "never": do not ever do anything, not even create - "create": the current behaviour, now the default behaviour - "warn": print a message if remote and local HEAD is different - "always": silently update HEAD on every change Signed-off-by: Bence Ferdinandy Signed-off-by: Junio C Hamano

Merge branch 'xx/remote-server-option-config'

2024-10-15T20:56:43Z

A new configuration variable remote..serverOption makes the transport layer act as if the --serverOption= option is given from the command line. * xx/remote-server-option-config: ls-remote: leakfix for not clearing server_options fetch: respect --server-option when fetching multiple remotes transport.c::handshake: make use of server options from remote remote: introduce remote..serverOption configuration transport: introduce parse_transport_option() method

remote: introduce remote..serverOption configuration

2024-10-08T17:22:07Z

Currently, server options for Git protocol v2 can only be specified via the command line option "--server-option" or "-o", which is inconvenient when users want to specify a list of default options to send. Therefore, we are introducing a new configuration to hold a list of default server options, akin to the `push.pushOption` configuration for push options. Initially, I named the new configuration `fetch.serverOption` to align with `push.pushOption`. However, after discussing with Patrick, it was renamed to `remote..serverOption` as suggested, because: 1. Server options are designed to be server-specific, making it more logical to use a per-remote configuration. 2. Using "fetch." prefixed configurations in git-clone or git-ls-remote seems out of place and inconsistent in design. The parsing logic for `remote..serverOption` also relies on `transport.c:parse_transport_option`, similar to `push.pushOption`, and they follow the same priority design: 1. Server options set in lower-priority configuration files (e.g., /etc/gitconfig or $HOME/.gitconfig) can be overridden or unset in more specific repository configurations using an empty string. 2. Command-line specified server options take precedence over those from the configuration. Server options from configuration are stored to the corresponding `remote.h:remote` as a new field `server_options`. The field will be utilized in the subsequent commit to help initialize the `server_options` of `transport.h:transport`. And documentation have been updated accordingly. Helped-by: Patrick Steinhardt Helped-by: Junio C Hamano Reported-by: Liu Zhongbo Signed-off-by: Xing Xin Reviewed-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

remote: fix leaking push reports

2024-09-30T18:23:08Z

The push reports that report failures to the user when pushing a reference leak in several places. Plug these leaks by introducing a new function `ref_push_report_free()` that frees the list of reports and call it as required. While at it, fix a trivially leaking error string in the vicinity. These leaks get hit in t5411, but plugging them does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

send-pack: free cas options before exit

2024-09-25T17:24:53Z

The send-pack --force-with-lease option populates a push_cas_option struct with allocated strings. Exiting without cleaning this up will cause leak-checkers to complain. We can fix this by calling clear_cas_option(), after making it publicly available. Previously it was used only for resetting the list when we saw --no-force-with-lease. The git-push command has the same "leak", though in this case it won't trigger a leak-checker since it stores the push_cas_option struct as a global rather than on the stack (and is thus reachable even after main() exits). I've added cleanup for it here anyway, though, as future-proofing. The leak is triggered by t5541 (it tests --force-with-lease over http, which requires a separate send-pack process under the hood), but we can't mark it as leak-free yet. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano