user/sven/git.git, branch v2.49.0-rc2

Git 2.49-rc2

2025-03-10T15:47:08Z

Signed-off-by: Junio C Hamano

Merge branch 'tb/fetch-follow-tags-fix'

2025-03-10T15:45:58Z

* tb/fetch-follow-tags-fix: fetch: fix following tags when fetching specific OID

fetch: fix following tags when fetching specific OID

2025-03-08T00:15:18Z

In 3f763ddf28 (fetch: set remote/HEAD if it does not exist, 2024-11-22), unconditionally adds "HEAD" to the list of ref prefixes we send to the server. This breaks a core assumption that the list of prefixes we send to the server is complete. We must either send all prefixes we care about, or none at all (in the latter case the server then advertises everything). The tag following code is careful to only add "refs/tags/" to the list of prefixes if there are already entries in the prefix list. But because the new code from 3f763ddf28 runs after the tag code, and because it unconditionally adds to the prefix list, we may end up with a prefix list that _should_ have "refs/tags/" in it, but doesn't. When that is the case, the server does not advertise any tags, and our auto-following breaks because we never learned about any tags in the first place. Fix this by only adding "HEAD" to the ref prefixes when we know that we are already limiting the advertisement. In either case we'll learn about HEAD (either through the limited advertisement, or implicitly through a full advertisement). Reported-by: Igor Todorovski Co-authored-by: Jeff King Signed-off-by: Jeff King Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

Merge branch 'js/win-2.49-build-fixes'

2025-03-06T22:06:32Z

Hotfix to help building Git-for-Windows. * js/win-2.49-build-fixes: cmake: generalize the handling of the `CLAR_TEST_OBJS` list meson: fix sorting ident: stop assuming that `gw_gecos` is writable

Merge branch 'pw/repo-layout-doc-update'

2025-03-06T22:06:31Z

Some future breaking changes would remove certain parts of the default repository, which were still described even when the documents were built for the future with WITH_BREAKING_CHANGES. * pw/repo-layout-doc-update: docs: fix repository-layout when building with breaking changes

Merge branch 'tz/doc-txt-to-adoc-fixes'

2025-03-06T22:06:31Z

Fallouts from recent renaming of documentation files from .txt suffix to the new .adoc suffix have been corrected. * tz/doc-txt-to-adoc-fixes: (38 commits) xdiff: *.txt -> *.adoc fixes unpack-trees.c: *.txt -> *.adoc fixes transport.h: *.txt -> *.adoc fixes trace2/tr2_sysenv.c: *.txt -> *.adoc fixes trace2.h: *.txt -> *.adoc fixes t6434: *.txt -> *.adoc fixes t6012: *.txt -> *.adoc fixes t/helper/test-rot13-filter.c: *.txt -> *.adoc fixes simple-ipc.h: *.txt -> *.adoc fixes setup.c: *.txt -> *.adoc fixes refs.h: *.txt -> *.adoc fixes pseudo-merge.h: *.txt -> *.adoc fixes parse-options.h: *.txt -> *.adoc fixes object-name.c: *.txt -> *.adoc fixes list-objects-filter-options.h: *.txt -> *.adoc fixes fsck.h: *.txt -> *.adoc fixes diffcore.h: *.txt -> *.adoc fixes diff.h: *.txt -> *.adoc fixes contrib/long-running-filter: *.txt -> *.adoc fixes config.c: *.txt -> *.adoc fixes ...

cmake: generalize the handling of the `CLAR_TEST_OBJS` list

2025-03-06T16:35:08Z

A late-comer to the v2.49.0 party, `sk/unit-test-oid`, added yet another array item to `CLAR_TEST_OBJS`, causing the `win+VS build` job to fail with symptoms like this one: unit-tests-lib.lib(u-oid-array.obj) : error LNK2019: unresolved external symbol cl_parse_any_oid referenced in function fill_array This is a similar scenario to the one that forced me to write 8afda42fce60 (cmake: generalize the handling of the `UNIT_TEST_OBJS` list, 2024-09-18): The hard-coded echo of `CLAR_TEST_OBJS` in `CMakeLists.txt` that recapitulates faithfully what was already hard-coded in `Makefile` would either have to be updated whack-a-mole style, or generalized. Just like I chose the latter option for `UNIT_TEST_OBJS`, I now do the same for `CLAR_TEST_OBJS`. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

meson: fix sorting

2025-03-06T16:35:07Z

In 904339edbd80 (Introduce support for the Meson build system, 2024-12-06) the `meson.build` file was introduced, adding also a Windows-specific list of source files. This list was obviously meant to be sorted alphabetically, but there is one mistake. Let's fix that. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ident: stop assuming that `gw_gecos` is writable

2025-03-06T16:35:07Z

In 590e081dea7c (ident: add NO_GECOS_IN_PWENT for systems without pw_gecos in struct passwd, 2011-05-19), code was introduced to iterate over the `gw_gecos` field; The loop variable is of type `char *`, which assumes that `gw_gecos` is writable. However, it is not necessarily writable (and it is a bad idea to have it writable in the first place), so let's switch the loop variable type to `const char *`. This is not a new problem, but what is new is the Meson build. While it does not trigger in CI builds, imitating the commands of `ci/run-build-and-tests.sh` in a regular Git for Windows SDK (`meson setup build . --fatal-meson-warnings --warnlevel 2 --werror --wrap-mode nofallback -Dfuzzers=true` followed by `meson compile -C build --` results in this beautiful error: "cc" [...] -o libgit.a.p/ident.c.obj "-c" ../ident.c ../ident.c: In function 'copy_gecos': ../ident.c:68:18: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 68 | for (src = get_gecos(w); *src && *src != ','; src++) { | ^ cc1.exe: all warnings being treated as errors Now, why does this not trigger in CI? The answer is as simple as it is puzzling: The `win+Meson` job completely side-steps Git for Windows' development environment, opting instead to use the GCC that is on the `PATH` in GitHub-hosted `windows-latest` runners. That GCC is pinned to v12.2.0 and targets the UCRT (unlikely to change any time soon, see https://github.com/actions/runner-images/blob/win25/20250303.1/images/windows/toolsets/toolset-2022.json#L132-L141). That is in stark contrast to Git for Windows, which uses GCC v14.2.0 and targets MSVCRT. Git for Windows' `Makefile`-based build also obviously uses different compiler flags, otherwise this compile error would have had plenty of opportunity in almost 14 years to surface. In other words, contrary to my expectations, the `win+Meson` job is ill-equipped to replace the `win build` job because it exercises a completely different tool version/compiler flags vector than what Git for Windows needs. Nevertheless, there is currently this huge push, including breaking changes after -rc1 and all, for switching to Meson. Therefore, we need to make it work, somehow, even in Git for Windows' SDK, hence this patch, at this point in time. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

A few more after -rc1

2025-03-05T18:37:53Z

Signed-off-by: Junio C Hamano