git/remote.c, branch v2.36.2

remote: read symbolic refs via `refs_read_symbolic_ref()`

2022-03-01T18:13:46Z

We have two cases in the remote code where we check whether a reference is symbolic or not, but don't mind in case it doesn't exist or in case it exists but is a non-symbolic reference. Convert these two callsites to use the new `refs_read_symbolic_ref()` function, whose intent is to implement exactly that usecase. No change in behaviour is expected from this change. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

refs API: remove "failure_errno" from refs_resolve_ref_unsafe()

2022-01-26T23:58:41Z

Remove the now-unused "failure_errno" parameter from the refs_resolve_ref_unsafe() signature. In my recent 96f6623ada0 (Merge branch 'ab/refs-errno-cleanup', 2021-11-29) series we made all of its callers explicitly request the errno via an output parameter. As that series shows all but one caller ended up passing in a boilerplate "ignore_errno", since they only cared about whether the return value was NULL or not, i.e. if the ref could be resolved. There was one small issue with that series fixed with a follow-up in 31e39123695 (Merge branch 'ab/refs-errno-cleanup', 2022-01-14) a small bug in that series was fixed. After those two there was one caller left in sequencer.c that used the "failure_errno', but as of the preceding commit it uses a boilerplate "ignore_errno" instead. This leaves the public refs API without any use of "failure_errno" at all. We could still do with a bit of cleanup and generalization between refs.c and refs/files-backend.c before the "reftable" integration lands, but that's all internal to the reference code itself. So let's remove this output parameter. Not only isn't it used now, but it's unlikely that we'll want it again in the future. We'd like to slowly move the refs API to a more file-backend independent way of communicating error codes, having it use a "failure_errno" was only the first step in that direction. If this or any other function needs to communicate what specifically is wrong with the requested "refname" it'll be better to have the function set some output enum of well-defined error states than piggy-backend on "errno". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'gc/remote-with-fewer-static-global-variables'

2021-12-10T22:35:02Z

Code clean-up to eventually allow information on remotes defined for an arbitrary repository to be read. * gc/remote-with-fewer-static-global-variables: remote: die if branch is not found in repository remote: remove the_repository->remote_state from static methods remote: use remote_state parameter internally remote: move static variables into per-repository struct t5516: add test case for pushing remote refspecs

remote: die if branch is not found in repository

2021-11-19T06:31:19Z

In a subsequent commit, we would like external-facing functions to be able to accept "struct repository" and "struct branch" as a pair. This is useful for functions like pushremote_for_branch(), which need to take values from the remote_state and branch, even if branch == NULL. However, a caller may supply an unrelated repository and branch, which is not supported behavior. To prevent misuse, add a die_on_missing_branch() helper function that dies if a given branch is not from a given repository. Speed up the existence check by replacing the branches list with a branches_hash hashmap. Like read_config(), die_on_missing_branch() is only called from non-static functions; static functions are less prone to misuse because they have strong conventions for keeping remote_state and branch in sync. Signed-off-by: Glen Choo Reviewed-by: Jonathan Tan Signed-off-by: Junio C Hamano

remote: remove the_repository->remote_state from static methods

2021-11-19T06:31:19Z

Replace all remaining references of the_repository->remote_state in static functions with a struct remote_state parameter. To do so, move read_config() calls to non-static functions and create a family of static functions, "remotes_*", that behave like "repo_*", but accept struct remote_state instead of struct repository. In the case where a static function calls a non-static function, replace the non-static function with its "remotes_*" equivalent. Signed-off-by: Glen Choo Reviewed-by: Jonathan Tan Signed-off-by: Junio C Hamano

remote: use remote_state parameter internally

2021-11-19T06:31:19Z

Without changing external-facing functions, replace the_repository->remote_state internally by adding a struct remote_state parameter. As a result, external-facing functions are still tied to the_repository, but most static functions no longer reference the_repository->remote_state. The exceptions are those that are used in a way that depends on external-facing functions e.g. the callbacks to remote_get_1(). Signed-off-by: Glen Choo Reviewed-by: Jonathan Tan Signed-off-by: Junio C Hamano

remote: move static variables into per-repository struct

2021-11-19T06:31:19Z

remote.c does not works with non-the_repository because it stores its state as static variables. To support non-the_repository, we can use a per-repository struct for the remotes subsystem. Prepare for this change by defining a struct remote_state that holds the remotes subsystem state and move the static variables of remote.c into the_repository->remote_state. This introduces no behavioral or API changes. Signed-off-by: Glen Choo Reviewed-by: Jonathan Tan Signed-off-by: Junio C Hamano

.[ch] _INIT macros: use { 0 } for a "zero out" idiom

2021-09-27T21:47:59Z

In C it isn't required to specify that all members of a struct are zero'd out to 0, NULL or '\0', just providing a "{ 0 }" will accomplish that. Let's also change code that provided N zero'd fields to just provide one, and change e.g. "{ NULL }" to "{ 0 }" for consistency. I.e. even if the first member is a pointer let's use "0" instead of "NULL". The point of using "0" consistently is to pick one, and to not have the reader wonder why we're not using the same pattern everywhere. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'cb/remote-ndebug-fix'

2021-09-10T18:46:30Z

Build fix. * cb/remote-ndebug-fix: remote: avoid -Wunused-but-set-variable in gcc with -DNDEBUG

remote: avoid -Wunused-but-set-variable in gcc with -DNDEBUG

2021-09-02T20:13:19Z

In make_remote(), we store the return value of hashmap_put() and check it using assert(), but don't otherwise use it. If Git is compiled with NDEBUG, then the assert() becomes a noop, and nobody looks at the variable at all. This causes some compilers to produce warnings. Let's switch it instead to a BUG(). This accomplishes the same thing, but is always compiled in (and we don't have to worry about the cost; the check is cheap, and this is not a hot code path). Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

git/remote.c, branch v2.36.2

remote: read symbolic refs via `refs_read_symbolic_ref()`

refs API: remove "failure_errno" from refs_resolve_ref_unsafe()

Merge branch 'gc/remote-with-fewer-static-global-variables'

remote: die if branch is not found in repository

remote: remove the_repository->remote_state from static methods

remote: use remote_state parameter internally

remote: move static variables into per-repository struct

*.[ch] *_INIT macros: use { 0 } for a "zero out" idiom

Merge branch 'cb/remote-ndebug-fix'

remote: avoid -Wunused-but-set-variable in gcc with -DNDEBUG

.[ch] _INIT macros: use { 0 } for a "zero out" idiom