You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose making Git for Windows artifacts reproducible: given the same source tag and SDK snapshot, rebuilding should produce byte-identical binaries and archives. This lets anyone independently verify that an official release was built from the published sources.
The MSYS2 project already treats SOURCE_DATE_EPOCH as the reproducibility convention for the toolchain (see msys2-teststoolchain/custom/test-reproducible), so this is a natural fit for Git for Windows, which builds on the same MSYS2/MinGW toolchain.
What I have verified
On GitHub Actions, with SOURCE_DATE_EPOCH fixed to the source-tag commit time, I verified that:
Compile determinism: building the mingw-w64-git package twice yields byte-identical results, after handling:
GIT-VERSION-GEN version drift when building outside a release tag (pin via the version file mechanism)
the git.manifest CRLF vs LF line endings
the CodeView PDB GUID that the linker/cv2pdb stamps into the .debug section (drop it at the end of build())
Packaging determinism: the portable, MinGit and tar archives are byte-identical across two runs (release-script mtime pinning + -mta- -mtc-).
The installer is reproducible except for the gzip header mtime that Inno Setup embeds at compile time. Inno Setup does not yet honor SOURCE_DATE_EPOCH; that is a separate upstream change (jrsoftware/issrc).
Reproducible builds for Git for Windows
Summary
I would like to propose making Git for Windows artifacts reproducible: given the same source tag and SDK snapshot, rebuilding should produce byte-identical binaries and archives. This lets anyone independently verify that an official release was built from the published sources.
The MSYS2 project already treats
SOURCE_DATE_EPOCHas the reproducibility convention for the toolchain (seemsys2-teststoolchain/custom/test-reproducible), so this is a natural fit for Git for Windows, which builds on the same MSYS2/MinGW toolchain.What I have verified
On GitHub Actions, with
SOURCE_DATE_EPOCHfixed to the source-tag commit time, I verified that:mingw-w64-gitpackage twice yields byte-identical results, after handling:GIT-VERSION-GENversion drift when building outside a release tag (pin via theversionfile mechanism)git.manifestCRLF vs LF line endings.debugsection (drop it at the end ofbuild())-mta- -mtc-).SOURCE_DATE_EPOCH; that is a separate upstream change (jrsoftware/issrc).Proposed changes / PRs
SOURCE_DATE_EPOCHin the release scripts (installer, portable, mingit, archive). PR: release scripts: support reproducible builds via SOURCE_DATE_EPOCH build-extra#730GIT-VERSION-GENversion pin, manifest LF, drop CodeView GUID). (preparing)SOURCE_DATE_EPOCHin the artifact workflow so CI produces reproducible artifacts. (preparing)SOURCE_DATE_EPOCHfor the embedded gzip header mtime. (preparing)Questions for the maintainers
SOURCE_DATE_EPOCHvalue should be pinned (e.g. the source-tag commit time vs a fixed value)?SOURCE_DATE_EPOCHby default, or keep it opt-in for now?I'm happy to split, adjust, or rebase the PRs based on feedback.