The existing build-git-installers.yml workflow did not handle building release candidate builds correctly, mainly because it hasn't been exercised with a real release candidate build.

During the rc-stages of v2.51.0, various issues were uncovered:

• The tag validation was looking for the wrong format. Release candidate tags look like v2.X.Y-rcN.vfs.W.Z, but it was checking for a tag like v2.X.Y.vfs.W.Z.rcN.
• The GIT-VERSION-GEN script does some munging of the tag to get to the build version. Specifically the -rc part is replaced with .rc and the leading v is dropped.. so a tag of v2.51.0-rc0.vfs.0.0 will become 2.51.0.rc0.vfs.0.0. The macOS installed Makefile and scripts to create the Debian package did not correctly account for this, leading to build strings that were not consistent with those for Windows builds.

With these changes, we can now successfully build release candidate versions. Tags must be of the form:

v2.X.Y-rcN.vfs.W.Z

The resulting build version (output from git --version) looks like:

2.X.Y.rcN.vfs.W.Z

Installer and package file names maintain the tag version format, for example:

• Git-2.51.0-rc0.vfs.0.0-{64-bit,arm64}.exe
• PortableGit-2.51.0-rc0.vfs.0.0-{64-bit,arm64}.7z.exe
• git-2.51.0-rc0.vfs.0.0-universal.{pkg,dmg}
• microsoft-git_2.51.0-rc0.vfs.0.0.deb

See an example successful build here: https://github.com/microsoft/git/actions/runs/16830521090

VFS for Git recently learned to correctly parse these release candidate version strings here: microsoft/VFSForGit#1854