git, branch v2.35.0-rc1

Git 2.35-rc1

2022-01-14T23:26:53Z

Signed-off-by: Junio C Hamano

Merge branch 'js/t1450-making-it-writable-does-not-need-full-posixperm'

2022-01-14T23:25:15Z

Test fix. * js/t1450-making-it-writable-does-not-need-full-posixperm: t1450-fsck: exec-bit is not needed to make loose object writable

Merge branch 'ab/reftable-build-fixes'

2022-01-14T23:25:15Z

A few portability tweaks. * ab/reftable-build-fixes: reftable tests: avoid "int" overflow, use "uint64_t" reftable: avoid initializing structs from structs

Merge branch 'ab/refs-errno-cleanup'

2022-01-14T23:25:15Z

A brown-paper-bag fix on top of a topic that was merged during this cycle. * ab/refs-errno-cleanup: refs API: use "failure_errno", not "errno"

reftable tests: avoid "int" overflow, use "uint64_t"

2022-01-13T21:39:09Z

Change code added in 1ae2b8cda84 (reftable: add merged table view, 2021-10-07) to consistently use the "uint64_t" type. These "min" and "max" variables get passed in the body of this function to a function whose prototype is: [...] reftable_writer_set_limits([...], uint64_t min, uint64_t max This avoids the following warning on SunCC 12.5 on gcc211.fsffrance.org: "reftable/merged_test.c", line 27: warning: initializer does not fit or is out of range: 0xffffffff Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

reftable: avoid initializing structs from structs

2022-01-13T21:36:34Z

Apparently, the IBM xlc compiler doesn't like this. Signed-off-by: Han-Wen Nienhuys Signed-off-by: Junio C Hamano

t1450-fsck: exec-bit is not needed to make loose object writable

2022-01-13T20:36:12Z

A test case wants to append stuff to a loose object file to ensure that this kind of corruption is detected. To make a read-only loose object file writable with chmod, it is not necessary to also make it executable. Replace the bitmask 755 with the instruction +w to request only the write bit and to also heed the umask. And get rid of a POSIXPERM prerequisite, which is unnecessary for the test. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

refs API: use "failure_errno", not "errno"

2022-01-13T18:53:54Z

Fix a logic error in refs_resolve_ref_unsafe() introduced in a recent series of mine to abstract the refs API away from errno. See 96f6623ada0 (Merge branch 'ab/refs-errno-cleanup', 2021-11-29)for that series. In that series introduction of "failure_errno" to refs_resolve_ref_unsafe came in ef18119dec8 (refs API: add a version of refs_resolve_ref_unsafe() with "errno", 2021-10-16). There we'd set "errno = 0" immediately before refs_read_raw_ref(), and then set "failure_errno" to "errno" if errno was non-zero afterwards. Then in the next commit 8b72fea7e91 (refs API: make refs_read_raw_ref() not set errno, 2021-10-16) we started expecting "refs_read_raw_ref()" to set "failure_errno". It would do that if refs_read_raw_ref() failed, but it wouldn't be the same errno. So we might set the "errno" here to any arbitrary bad value, and end up e.g. returning NULL when we meant to return the refname from refs_resolve_ref_unsafe(), or the other way around. Instrumenting this code will reveal cases where refs_read_raw_ref() will fail, and "errno" and "failure_errno" will be set to different values. In practice I haven't found a case where this scary bug changed anything in practice. The reason for that is that we'll not care about the actual value of "errno" here per-se, but only whether: 1. We have an errno 2. If it's one of ENOENT, EISDIR or ENOTDIR. See the adjacent code added in a1c1d8170db (refs_resolve_ref_unsafe: handle d/f conflicts for writes, 2017-10-06) I.e. if we clobber "failure_errno" with "errno", but it happened to be one of those three, and we'll clobber it with another one of the three we were OK. Perhaps there are cases where the difference ended up mattering, but I haven't found them. Instrumenting the test suite to fail if "errno" and "failure_errno" are different shows a lot of failures, checking if they're different *and* one is but not the other is outside that list of three "errno" values yields no failures. But let's fix the obvious bug. We should just stop paying attention to "errno" in refs_resolve_ref_unsafe(). In addition let's change the partial resetting of "errno" in files_read_raw_ref() to happen just before the "return", to ensure that any such bug will be more easily spotted in the future. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Last minute fixes before -rc1

2022-01-13T00:27:08Z

Signed-off-by: Junio C Hamano

Merge branch 'ps/lockfile-cleanup-fix'

2022-01-12T23:11:43Z

Some lockfile code called free() in signal-death code path, which has been corrected. * ps/lockfile-cleanup-fix: fetch: fix deadlock when cleaning up lockfiles in async signals