# build-extra is the assembly line behind the Git for Windows installer > The git-for-windows build-extra repository holds the scripts, package recipes and installer definitions used to build Git for Windows on MSYS2. It matters to contributors and packagers, not to people who install Git, and its most recent tagged SDK release is years old despite work continuing in 2026. **git-for-windows/build-extra** — Additional files and scripts to help build Git for Windows on MSYS2. - Repository: https://github.com/git-for-windows/build-extra - Stars: 677 · Forks: 656 - Language: Inno Setup - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/git-for-windows-build-extra ## The repository that glues a Git fork to MSYS2 build-extra is described in its own README as a core part of the Git for Windows SDK, the build environment for Git for Windows. It is not the Git source code, and it is not the installer itself. It is the set of additional files and scripts that let a Windows machine build Git for Windows, and the README points contributors at the project's main Git fork for issue reports, which tells you where the division of labour sits. The scope is wider than the name suggests. The top level contains an installer/ directory for the end user installer, a portable/ directory for the self extracting archive edition, an sdk-installer/ directory for the developer SDK, an msi/ directory, an msbuild/ directory, a nuget/ directory, an archive/ directory, and a mingit/ directory. There are also component directories for things that ship inside the installation, such as git-extra/, git-for-windows-keyring/, mingw-w64-git-credential-manager/, mingw-w64-git-lfs/, mingw-w64-git-sizer/ and mingw-w64-wintoast/. Then there is the supporting cast: a shears.sh script that helps with merging new upstream Git releases into the Windows fork, an aslr-manager.ps1 for address space layout randomization, a signtool.sh, a send-to-virus-total.sh, a check-for-missing-dlls.sh, a download-stats.sh, and an ever-green.sh. The primary language recorded for the repository is Inno Setup, which is the installer authoring tool, and the Makefile at the root is a small C build. The people who need this repository are contributors to the Windows port, downstream packagers who ship their own Git for Windows builds, and anyone reproducing a release for audit or air gap installation. ## MSYS2 for the scripts, MinGW for the speed The README explains the two toolchain families, and the difference is the key to understanding the whole build. Git is not a single executable. It consists of a couple of C executables, some Bash scripts, some Perl scripts and some Tcl/Tk scripts, with other languages still appearing in parts Git for Windows does not support yet. Those scripts need a POSIX-like environment, and that is what MSYS2 provides: a minimal POSIX emulation layer based on Cygwin, a package manager called Pacman borrowed from Arch Linux, and packages kept current by a maintainer team, including Bash, Perl and Subversion. MSYS2 binaries use Cygwin's cygwin1.dll, which means most POSIX semantics are emulated well, including the fork() function, and porting from Unix is straightforward. The catch is performance. The README states that MSYS2 programs are typically noticeably slower than their MinGW counterparts, and that as a consequence the project tries to ship as many components as possible as MinGW binaries. MinGW is the other family. Those libraries and programs are compiled with GNU tools but do not require POSIX semantics, relying instead on the standard Win32 API and the C runtime library, which is what the name Minimal GNU for Windows refers to. cURL, emacs and Inkscape are the examples given. So the split is: MSYS2 where POSIX semantics are required, MinGW where speed matters and the Win32 API will do. ## Getting into the Git SDK and checking out build-extra The README says the easiest way to install the SDK is via the Git SDK installer, linked from the repository's releases page. The installer clones the project's repositories, including all the necessary components, performs an initial build, and puts a shortcut to the Git SDK Bash on the desktop. That last detail matters: the rest of the workflow happens in that shell, not in cmd or PowerShell. Once the SDK is installed, the build-extra checkout is refreshed with three commands issued in the Git SDK Bash: ```sh cd /usr/src/build-extra git fetch git checkout main ``` The pattern is the same for the two package repositories. The MinGW packages are built from the MINGW-packages repository, and the MSYS2 packages from the MSYS2-packages repository, each initialized in the same way: ```sh cd /usr/src/MINGW-packages git fetch git checkout main ``` and: ```sh cd /usr/src/MSYS2-packages git fetch git checkout main ``` So the SDK ships with working trees, and refreshing them is a fetch plus a checkout of the main branch. Nothing here requires a release tag, which is consistent with the fact that the tagged releases in this repository have not moved in years while the branches do. ## MinGW packages build with makepkg-mingw and a dual toolchain Building the MinGW side is the simpler of the two. The packages inside /usr/src/MINGW-packages/ are built by executing makepkg-mingw -s in the appropriate subdirectory, where the -s flag installs the dependencies the recipe declares. One wrinkle is architecture. MinGW packages can be built for both i686 and x86_64 at the same time, provided both toolchains are present, and the README gives the pacman invocation that installs the mingw-w64-i686-toolchain and mingw-w64-x86_64-toolchain packages. Installing both toolchains is what lets a single makepkg-mingw invocation produce 32 bit and 64 bit artifacts in one pass. A packager who only needs one architecture still has to install both, since the recipe path is the same either way, and the cost is the toolchain download rather than anything in the build itself. The practical takeaway is that the MinGW half is a conventional package build driven by Pacman style recipes, executed by makepkg-mingw from a directory tree that the SDK installer has already cloned for you. ## MSYS2 packages need the special shell and base-devel first The MSYS2 side has an extra step and a different shell. To build packages in /usr/src/MSYS2-packages/, the user has to launch a special shell by double clicking the msys2_shell.bat script in the top level directory of the Git SDK, switch to the relevant subdirectory, and then run makepkg -s. Before the first MSYS2 package is built, the prerequisite development packages have to be installed with a pacman command that pulls in base-devel and binutils. The requirement for a separate shell and a one time bootstrap install is the practical friction of this part of the build. The msys2_shell.bat entry point selects the right environment for MSYS2 packages, which are POSIX oriented, rather than the MinGW environment, and the base-devel and binutils packages supply the toolchain the recipes expect. For anyone coming from a Linux package build, the model will feel familiar: recipes, a package manager, a -s flag for dependencies. The unfamiliar parts are Windows specific, namely the batch script that launches the correct shell and the fact that the package trees live under /usr/src inside the SDK. ## Three installers are generated from one source tree The README says the project aims to provide three kinds of installer, each generated from a different directory of this repository. The Git for Windows installer for end users comes from installer/. The portable edition, described as the USB drive edition that runs without installing from wherever it is unpacked, comes from portable/, and is actually a self extracting .7z archive rather than a conventional installer. The Git for Windows SDK for contributors comes from sdk-installer/, and is a complete development environment including Git, Bash and cURL, and of course the other two installers as well. The portable detail is the interesting one for security conscious distribution. A self extracting archive that runs from a USB stick has a different audit profile from an MSI that installs into Program Files, and the repository carries separate msi/ and nuget/ directories, so the packaging formats a downstream consumer might want, a Windows installer, an MSI and a NuGet package, are all handled by the same tree. The repository also carries the release note machinery. There is a ReleaseNotes.md, a ReleaseNotes.css, an add-release-note.js helper and a render-release-notes.sh script, which together suggest that the notes shown to users when an update lands are generated from data in the tree rather than written by hand each time. ## A custom licence and a release tag that stopped moving in 2020 The licence needs attention. The project record lists it as Other, with a note that it is a custom licence GitHub could not classify and that the LICENSE file should be read. The repository root carries LICENSE.txt rather than a standard LICENSE, and there is also a gpl-2.0.rtf file, which is presumably the text of a GPL version 2 licence shipped as a resource for the components that require it. Since this is a custom grant rather than a standard one, anyone redistributing a build should read LICENSE.txt directly and check which obligations it places on the binary and its sources. The release history is the other thing to understand before you plan around versions. The most recent tags are git-sdk-1.0.8 from 2020-10-24, git-sdk-1.0.7 from 2018-04-11 and git-sdk-1.0.6 from 2017-07-12. Those are the tags attached to the SDK installer that the README points at as the way in, and they have not been refreshed in years. Meanwhile the branches move. The last push was on 2026-10-15, and the working tree is where the current state of the build lives. The practical conclusion is that you should treat main as the version of record for this repository, and the tags as historical markers rather than as a release cadence. The root Makefile is a small illustration of the mixed toolchain in play: ``` CFLAGS=-O2 -Wall all: edit-git-bash.exe edit-git-bash.exe: edit-git-bash.c gcc -DSTANDALONE_EXE $(CFLAGS) -o $@ $^ ``` It compiles edit-git-bash.c into a standalone executable, one of the small utilities the SDK uses to tweak the Git Bash shortcut on a Windows desktop. There is also an AGENTS.md file at the root, which suggests the project has been through an effort to describe its conventions for automated tooling. ## Conclusion Adopt build-extra if you are building Git for Windows yourself, maintaining a downstream Windows distribution of Git, or working on the Windows-specific patches that the project develops against its own fork before submitting them upstream. Do not adopt it to install Git on a machine, since the Git SDK installer already bundles everything you need for that, and do not rely on its release tags as a version signal, because the newest published tag is git-sdk-1.0.8 from 2020-10-24 while the last push was on 2026-10-15. Before you start, read the LICENSE.txt file yourself, since the project carries a custom licence that GitHub could not classify, and plan for a build that needs both the MSYS2 shell and the MinGW toolchains installed side by side. ## FAQ ### What is the git-for-windows build-extra repository for? It holds the additional files and scripts needed to build Git for Windows on MSYS2, including the installer definitions for the end user installer, the portable archive and the Git SDK, plus support scripts such as the upstream merge helper shears.sh. ### How do I install the Git for Windows SDK? The README points to the Git SDK installer on the repository's releases page. The installer clones the project repositories, performs an initial build and adds a shortcut to the Git SDK Bash on the desktop. ### What is the difference between MSYS2 and MinGW in the Git for Windows build? MSYS2 provides a POSIX emulation layer based on Cygwin plus the Pacman package manager, and its programs are typically noticeably slower. MinGW programs are compiled with GNU tools but rely on the standard Win32 API instead, and Git for Windows tries to ship as many components as possible as MinGW binaries. ### Which build-extra release should I use for the Git SDK installer? The newest published tag is git-sdk-1.0.8 from 2020-10-24, but the last push to the repository was on 2026-10-15, so the main branch is the current state of the build. Refresh it inside the Git SDK Bash with git fetch and git checkout main. ## Sources - [git-for-windows/build-extra on GitHub](https://github.com/git-for-windows/build-extra) - [Issues](https://github.com/git-for-windows/build-extra/issues) - [README](https://github.com/git-for-windows/build-extra/blob/main/README.md) - [Releases](https://github.com/git-for-windows/build-extra/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/git-for-windows-build-extra