Conversation
shmuelie
force-pushed
the
add-msix-installer
branch
from
f4a9629 to
aa67f47
Compare
shmuelie
force-pushed
the
add-msix-installer
branch
2 times, most recently
from
8f9cff5 to
9e28cd5
Compare
dscho
left a comment
dscho
left a comment
There was a problem hiding this comment.
Hi @shmuelie,
Thank you for working on this. MSIX packaging for Git for Windows is something that was attempted a couple of times, and I appreciate you picking it up. That said, this PR needs significant rework before I can consider merging it. Let me walk through the concerns.
Commit history. In Git for Windows we polish commits to tell a clean, compelling story. The current history reads like a lab notebook: "Initial prototype for MSIX creation", "Minor cleanup", "Initial release script", "Fix generated package name", "Fix manifest", followed by five Copilot-assisted fixup commits. Errors should be squashed into the commits that introduced them, not stacked on top. Please rework the branch into a small number of logical, self-contained commits that each do one thing correctly. For example, one commit could refactor portable/release.sh to separate out reusable parts, and the next one could add a minimal manifest template with the release.sh script to build an MSIX, another the asset generation (see below). Each commit message should explain why, not just what.
Committed image assets. The PR adds 8 PNG files under msix/Assets/. I would much rather see a small automation step that generates these from the git-for-windows.png (or git-for-windows.svg) already in the repo root at build time, resizing to the required dimensions. I notice that several of the committed PNGs share the same blob hash (3 files are identical at b5c5143, 2 more at fa651cf), which reinforces that these are mechanically derived. Committing generated binary artifacts that cannot easily be manually recreated or verified is something I try to avoid. If generating them at build time is truly not feasible, that needs justification. You could then still follow the example in gitforwindows.org where generated files are committed, but are accompanied with easy, reproducible steps to recreate them.
Configurability. Previous attempts at MSIX/Store packaging ran into a fundamental problem: the Git for Windows installer allows extensive configuration (default editor, line endings, PATH modifications, credential helper, terminal emulator, etc.), but an MSIX package has no such configuration UI. The script currently hardcodes credential.helper manager and core.fscache true into the system gitconfig, which is a reasonable starting point, but the PR description needs to address this gap explicitly. What defaults are baked in? How can users change them conveniently after installation and persist the changes across upgrades? The manifest declares desktop6:FileSystemWriteVirtualization and desktop6:RegistryWriteVirtualization as disabled, and requests unvirtualizedResources. Does that mean the packaged etc/gitconfig is writable by the user post-install? This needs to be documented.
Missing PR description. The PR currently has no description at all. It needs to explain at minimum: How to build the MSIX artifact (the exact commands; note that the script's opening comment still says "Build the portable Git for Windows", suggesting it was copy-pasted from portable/release.sh without updating). How to code-sign the resulting .msix, or how to install it without signing (MSIX packages must be signed, or the user must enable Developer Mode). How to actually use the result: does it work? What does the user experience look like? Does git-bash.exe launch correctly from the Start Menu? Whether the execution aliases (git.exe, bash.exe, sh.exe, nano.exe) clash with a regular Git for Windows installation on the same machine. Registering bash.exe and sh.exe as app execution aliases seems particularly aggressive for users who have WSL or Cygwin installed. Whether the MSIX package can provide a central Git config analogous to C:\Program Files\Git\etc\gitconfig (which Git for Windows' installer provides, and which MinGit picks up so that tools like Visual Studio, VS Code, and SmartGit can rely on the central file for shared configuration).
Relationship to existing stale msix/ content. The msix/ directory already contains appxmanifest.xml, PackagingLayout.xml, Microsoft.Alm.Authentication.dll, WebView2Loader.dll, and stale .appx/.appxbundle binaries from a previous abandoned attempt (dating back to the Git 2.32 era). This PR adds a new appxmanifest.xml.in alongside the existing appxmanifest.xml without removing or replacing the old files. This needs to be cleaned up, and that cleanup deserves its own commit at the start of the series with a brief explanation of what the old files were and why they are being replaced.
Publisher identity. The new appxmanifest.xml.in uses Publisher="CN=The Git Development Community" and Name="Git.GitforWindows", while the old appxmanifest.xml uses Publisher="CN=Johannes Schindelin, ..." and Name="JohannesSchindelin.Git". The publisher string in an MSIX must match the signing certificate exactly, so this is not a cosmetic choice. Can you explain the rationale for the new identity?
I am genuinely impressed by the effort you put in, and want to assist so that you can succeed. The approach of reusing make-file-list.sh and basing this on the MinGit/portable infrastructure looks right. But the PR needs the rework described above: clean commit history, following the DRY principle, generated (ideally not committed) assets, cleanup of the stale files, and most importantly a thorough PR description that addresses the configurability and coexistence questions.
Thank you!
|
This PR adds code for building an MSIX on x86, amd64 and arm64. I don't think we'll ever want to publish a MSIX for x86, though.
I also have questions about these aliases. |
|
Awesome, thank you for the feedback. I was honestly so overjoyed to get something that works I forgot to think about other things 😅. Hope to take a look at each point tonight and get back to you! |
|
Commit history: Happy to do that, and yeah... you can clearly see the history of me trying to get it working. Will rework the history as I work on the other issues Committed image assets: They were generated from the SVG as you suggested. The tool I used is not free or open source so I wouldn't want to add it to the build pipeline. I will look for a way to generate them in the pipeline though Configurability: There are a couple of options here. MSIX packages can have locations that are user editable to allow configuring the system level configuration, though that is not what the feature you mentioned are about. Those features are so that the applications in the package don't see a virtualized version of the file system. As for the PATH editing, that would not be needed as that's why the aliases are for. Aliases can be turned on and off in Windows Settings, allowing users to choose which are enabled from the package. Missing PR description: Very good points. I will edit the PR description and the script. Thought I had changed all the messages but guess I missed a few 😅 Relationship to existing stale Publisher identity: I just put values there so I would have something to work with, very likely we'd have to change those. As for the questions about the various alias: In the packaged world, you don't modify the PATH, instead for every application you can create one or more aliases that have kind of symbolic links created for them. As I noted above, each alias can be individually turned on or off to help the user select what will be found. This can even work with multiple packages declaring the same aliases. |
|
@dscho I have updated the PR description. Still missing build instructions but want to make some changes before I add that |
shmuelie
force-pushed
the
add-msix-installer
branch
from
9e28cd5 to
397d238
Compare
The portable and MSIX release scripts share significant logic: argument parsing, MSYSTEM/architecture detection, root directory setup, file list generation, gitconfig configuration, DLL copying, and PDB handling. Extract these into release-common.sh as a shared include with reusable functions (prepare_root, init_etc_gitconfig, generate_file_list, copy_dlls_to_libexec, unpack_pdbs), and refactor portable/release.sh to source it. No behavioral change to portable builds. Signed-off-by: Shmueli Englard <shmueli.yosef@englard.net> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add appxmanifest.xml.in defining the MSIX package structure for Git for Windows. The manifest declares applications for Git Bash, Git CMD, and Git GUI (with Start Menu entries), plus execution aliases for git.exe, bash.exe, sh.exe, and nano.exe. It requests unvirtualized filesystem and registry access so the packaged gitconfig remains writable post-install. The @@Version@@ placeholder is substituted at build time to produce the required X.X.X.X version format. Also add msix/root/ to .gitignore since it is generated during builds. Signed-off-by: Shmueli Englard <shmueli.yosef@englard.net>
Add msix/release.sh to build MSIX packages for Git for Windows. The script reuses the shared helpers from release-common.sh for argument parsing, root directory setup, file list generation, and gitconfig configuration. MSIX-specific logic includes: - Converting Git for Windows version strings to the X.X.X.X format required by MSIX (e.g. 2.47.1.windows.1 becomes 2.47.1.1) - Generating asset images at build time from git-for-windows.svg using rsvg-convert, avoiding committed binary artifacts - Locating makeappx.exe from the Windows SDK to produce the final .msix package Signed-off-by: Shmueli Englard <shmueli.yosef@englard.net> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
shmuelie
force-pushed
the
add-msix-installer
branch
from
397d238 to
cac87a9
Compare
|
@dscho I've cleaned the commit history, changed to generate the images, and updated the PR description with all the details you asked for 😄 |
| <Identity | ||
| Name="Git.GitforWindows" | ||
| Publisher="CN=The Git Development Community" | ||
| Version="@@VERSION@@" /> |
There was a problem hiding this comment.
The @@VERSION@@ placeholder makes sense. Nit: The commit message talks about @@Version@@ instead.
| <Application Id="GitGui" Executable="cmd\git-gui.exe" uap10:RuntimeBehavior="win32App" uap10:TrustLevel="mediumIL"> | ||
| <uap3:VisualElements | ||
| DisplayName="Git GUI" | ||
| Description="Git GUI - Windows graphical interface for Git" |
There was a problem hiding this comment.
| Description="Git GUI - Windows graphical interface for Git" | |
| Description="Git GUI - Graphical interface for Git" |
| <DisplayName>Git for Windows</DisplayName> | ||
| <PublisherDisplayName>The Git Development Community</PublisherDisplayName> | ||
| <Logo>Assets\StoreLogo.png</Logo> | ||
| <Description>Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of the Git to Windows while providing appropriate user interfaces for experienced users.</Description> |
There was a problem hiding this comment.
| <Description>Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of the Git to Windows while providing appropriate user interfaces for experienced users.</Description> | |
| <Description>Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of Git to Windows while providing appropriate user interfaces for experienced users.</Description> |
I don't think I've ever seen "the Git" in any reasonably formal writing.
| </Properties> | ||
|
|
||
| <Dependencies> | ||
| <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.19041.0" MaxVersionTested="10.0.26100.0" /> |
There was a problem hiding this comment.
Does the MinVersion also need a placeholder, so we can switch it to 10.0.2XXX.0 on CLANGARM64 (due to the requirement for x64 emulation)?
| </uap3:Extension> | ||
| </Extensions> | ||
| </Application> | ||
| <Application Id="Bash" Executable="bin\bash.exe" uap10:RuntimeBehavior="win32App" uap10:TrustLevel="mediumIL"> |
There was a problem hiding this comment.
What's the purpose of the bash alias? It would allow MSIX users to create their own Windows Terminal profile, so it might be usefull.
| . "$(dirname "$0")/../release-common.sh" | ||
|
|
||
| case "$MSYSTEM" in | ||
| MINGW32) ARTIFACT_SUFFIX="x86";; |
There was a problem hiding this comment.
I don't think we'll need a MINGW32 MSIX.
|
|
||
| # MSIX requires version in X.X.X.X format (numeric only) | ||
| # Convert Git for Windows versions like "2.47.1.windows.1" to "2.47.1.1" | ||
| # and test versions like "0-test" to "0.0.0.0" |
There was a problem hiding this comment.
Do we have any plans how to handle snapshot and rc builds?
| ;; | ||
| MINGW32) ARTIFACT_SUFFIX="32-bit";; | ||
| MINGW64) ARTIFACT_SUFFIX="64-bit";; | ||
| CLANGARM64) ARTIFACT_SUFFIX=arm64;; |
There was a problem hiding this comment.
I'm surprised ARTIFACT_SUFFIX isn't common.
| BITNESS=64 | ||
| ARCH=aarch64 | ||
| ARTIFACT_SUFFIX=arm64 | ||
| MD_ARG=256M |
There was a problem hiding this comment.
I don't think MD_ARG should be common.
|
|
||
| case "$MSYSTEM" in | ||
| MINGW32) ARTIFACT_SUFFIX="x86";; | ||
| MINGW64) ARTIFACT_SUFFIX="x64";; |
There was a problem hiding this comment.
But this explains why the suffix isn't common. I'm not sure how I feel about introducing a different suffix for one artefact, though.
3 participants
What
This PR introduces creating an MSIX package for Git for Windows, in addition to the existing installers.
Why?
MSIX has a number of advantages over traditional MSI/EXE based installers on Windows. While not an exhaustive list, a few that affect Git are:
User Experience
After installation, the Start Menu shows entries for Git Bash, Git CMD, and Git GUI, grouped under "Git for Windows". Launching Git Bash opens a mintty terminal window identical to the traditional installer experience. Command-line usage via the execution aliases (
git,bash,sh) works the same as a PATH-based installation.Configuration Defaults
The MSIX package bakes in the following system gitconfig settings:
credential.helper manager(Git Credential Manager as the default credential helper)core.fscache truepack.packSizeLimitis unsetThe manifest declares
desktop6:FileSystemWriteVirtualizationanddesktop6:RegistryWriteVirtualizationas disabled and requests theunvirtualizedResourcescapability. This means the packagedetc/gitconfigis not virtualized — it lives at its real path and is writable by the user post-install, so changes made viagit config --systempersist in place. However, MSIX upgrades replace the package contents, so user customizations to the system gitconfig would need to be reapplied after updates. Users can avoid this by using--globalconfig instead, which lives in their home directory outside the package.Execution Aliases and Coexistence
The manifest registers execution aliases for
git.exe,git-bash.exe,git-cmd.exe,git-gui.exe,bash.exe,sh.exe, andnano.exe. Each alias can be individually enabled or disabled by the user in Windows Settings (Settings → Apps → Advanced app settings → App execution aliases).This means
bash.exeandsh.exewill not automatically shadow WSL, Cygwin, or other installations — the user controls which aliases are active. If a regular Git for Windows installation is also present, the user can toggle whichgit.exealias is active, or disable the MSIX aliases entirely to use the PATH-based installation.System Gitconfig Discoverability
MSIX packages install to a per-user location under
C:\Program Files\WindowsApps\...which is not a well-known fixed path. Tools like Visual Studio, VS Code, and SmartGit that look for Git atC:\Program Files\Git\etc\gitconfigwill not find the MSIX-packaged gitconfig at that path. These tools would need to discover Git via the execution alias (where.exe git) and resolve the config path from there. This is a known gap compared to the traditional installer.Known Issues and Limitations
Building
Build the MSIX package from a Git for Windows SDK shell (MINGW64):
For example:
This requires
rsvg-convert(frommingw-w64-x86_64-librsvg) to generate the package asset images, andmakeappx.exefrom a Windows 10 SDK installation.Installing Without Signing
MSIX packages must be signed to install normally. To install an unsigned package for testing, enable Developer Mode in Windows Settings (Settings → System → For developers → Developer Mode), then install with: