Installer does not roll back properly

[fourpastmidnight]

While installing Git 2.7.2, an error was encountered where C:\Program Files\Git\mingw64\bin was unable to be deleted. I was given a dialog with three choices: Abort, Retry, or Ignore. Well, it's fairly safe to say that ignoring this is not a good idea, and retrying didn't work (of course), so really, the only sensible option was to Abort.

When I clicked Abort, the status bar changed and said Rolling back.... However, my previous installation was now corrupted--as not all files were restored/rolled back. This is a pretty huge installer bug. The whole point of MSI's is that they're transactional.

If you're not going to support rolling back a failed installation, then remove the rollback steps in the installer.

[dscho]

The whole point of MSI's is that they're transactional.

We do not have an MSI.

If you're not going to support rolling back a failed installation, then remove the rollback steps in the installer.

How about you open a Pull Request and then we discuss how to continue?

[fourpastmidnight]

This was supposed to go under build-extra section of the Git for Windows GitHub repository. I apologize, I got the wrong issue tracker. And, it appears that the build-extra repository doesn't have an issue tracker.

[dscho]

This was supposed to go under build-extra section of the Git for Windows GitHub repository. I apologize, I got the wrong issue tracker. And, it appears that the build-extra repository doesn't have an issue tracker.

This is by design. We have a central bug tracker because it is unreasonable to ask users to figure out the correct repository.

Now, what about your PR?

[fourpastmidnight]

It's been a few years since I've really used WiX, so I'll try to look into the WiX project and see what I can make of it.

[fourpastmidnight]

Ok, just was Bing'ing around and found @robmen contribution that eventually resulted in the msi folder in the build-extra repo via your PR. At least I have something to work with :). It looks like the MSI installer project has been dormant since 19-JAN-2016. I'll see what I can make of it, but I may need help figuring out how to get it even better integrated into your build process. I see the release.sh file compiles a list of files to be installed and creates a WiX GitComponents.wxs file. I was able to successfully create a MSI, but since it's early in the development process, naturally, it's not as full-featured as the InnoSetup installer--yet. Hopefully, I can help improve that.

Of course, the whole thing that led to this issue was I thought I was using an MSI wrapped in a bootstrap EXE. I didn't realize the installer was InnoSetup. I'm hoping a MSI-based install will provide a better installation and upgrade experience, especially supporting rollback support.

[dscho]

Hopefully, I can help improve that.

That would be great!

Please note that I already wrote up a list of things that will need to be addressed before I can make official .msi installers: git-for-windows/build-extra#96 (comment)

[fourpastmidnight]

I already figured out why git-cmd.exe and git-bash.exe don't get installed: It's because of the sed script in release.sh and the actual location of these files. I'm working on mitigating that now. What are the [OPTIONS] that can be passed into release.sh?

The other things you mention are completely doable and I wouldn't ship an installer without those items, too.

Lastly, this might be more work, but, for instance, I never check the box to install the Git-GUI shortcut, I just don't need it. It would be great to not only not create a shortcut and context menu entry for Git-GUI, for example, but also to not install the required files for Git-GUI, either. Is there a way to know what all the dependencies are for git-bash.exe, git-cmd.exe and git-gui.exe? The MSI Feature tree could easily accomplish this. This doesn't need to be part of the initial release, but it would be nice.

[dscho]

I already figured out why git-cmd.exe and git-bash.exe don't get installed: It's because of the sed script in release.sh and the actual location of these files. I'm working on mitigating that now.

Very nice!

What are the [OPTIONS] that can be passed into release.sh?

Anything you want, really. The InnoSetup-backed script handles command-line options such as --force.

Is there a way to know what all the dependencies are for git-bash.exe, git-cmd.exe and git-gui.exe?

There is, but no automated one. For example, if you never want to call git gui nor gitk, you do not need Tcl/Tk. But the only way to know is to inspect the scripts to determine what requires what.

And it can get quite tricky to get it right. For example, if you do not want Git Bash, you also don't need usr/bin/bash,exe, right? Not so: parts of Git are still implemented as shell scripts, so they need a shell interpreter. So we could use usr/bin/dash.exe instead, correct? Again, not so: in preliminary experiments, many of Git's regression tests failed when using dash instead of bash.

[robmen]

Yeah, sorry, been pulled away for a couple months on other work. Still want to finish what was started but it won't happen in March.

[fourpastmidnight]

I've made good progress on adapting the existing release.sh and make-file-list.sh scripts, creating specific versions for generating the WiX source files. I anticipate completing those tomorrow.

Here's a rough outline of what's next:

1. Generating the WiX component *.wxs file(s) and check it/them for correctness
2. Create the WiX code necessary for the most basic installer UI
   • This installer will lack the ability to set the console, CRLF options, and SSH client.
   • It might not create all shortcuts
3. Modify the installer to bring it up to par with the existing InnoSetup installer.
   • E.g. Implement selecting console, CRLF options, and SSH client selection
4. Tidy up any loose ends
   • I'm hoping by this step, if not 3 above, we'll have a release-ready MSI installer
5. (Optional) Implement any desired setup enhancements, E.g. ability to not install Git-GUI if you don't want it, or any other enhancements.

[dscho]

@robmen no worries.

@fourpastmidnight excellent progress! Thank you so much! Any chance you can push your current state into https://github.com/fourpastmidnight?tab=repositories (I am curious)?

[fourpastmidnight]

@robmen same here, no worries.

@dscho Yeah, I just installed the SDK, but I'll need to fork the build-extra repo after "cleaning up my mess" ;)

I hope to have the bulk of the shell scripts squared away tonight--I'd like to get eyes on what I've done very soon before I go to much further.

Also, that plan was just my initial thoughts for a roadmap, so please feel free to make any suggestions or provide any other helpful feedback. :)

I'll look into getting build-extra forked. Is this the only repo I'll need to fork?

[dscho]

Is this the only repo I'll need to fork?

Yep.

[fourpastmidnight]

So, I got around to forking the build-extra repo, but I haven't committed anything. I have a fairly good idea of what I'm trying to accomplish, but as I was preparing to finalize the individual pieces, the solution is taking a slightly different turn than I expected. It's no big deal, but this revelation set me back a few hours.

Of course, it didn't help that my computer decided to be special tonight, so tonight was unexpectedly update night. Yay! Um, no, rather annoying. Oh well.

[dscho]

@fourpastmidnight oh yeah, I know those days! Keep up the good work!

[fourpastmidnight]

So that slightly different turn ended up being more complicated to figure out; but also, I wanted to ensure the correctness of what I'm doing as compared to my actual installation of Git for Windows, such as the number of packages that are listed and their constituent files.

I'm trying to finish the initial changes to the release.sh script to update the logic for generating the WiX component files. Once that's done, I'll push it up---I want to get eyes on it once these initial changes are complete. I'm hoping to have this completed by the end of the weekend.

[fourpastmidnight]

So, after dissecting the existing script and trying some things out, I've determined that my idea wasn't going to work as well as I would've liked. But, all is not lost.

The good news is that I've found a way to fix the generation of the GitComponents.wxs file so that the issue mentioned in Pull Request #96 with respect to git-bash.exe and git-cmd.exe not being installed has been resolved.

Also, when creating the installer from the original release.sh, upon examining the generated MSI installer database, it was properly referencing the ProgramFiles64Folder folder into which Git for Windows would be installed. In addition, I see the $WIX_ARCH bash variable being passed on the command line to candle.exe's -arch option. So it seems, based on the examination of the MSI database and the current invocation of candle.exe, that this issue has been resolved in some prior commit.

The other two issues mentioned in that pull request are still issues:

• The Start Menu group and shortcut links therein still require additional research. Shortcuts need to be specified in the same component as the file to which they point to. I have some ideas about how this might be done, but I need to research this a bit more.
• Off the top of my head, it seems the "post-install.bat file being left behind" issue will require a custom action to be run to execute this file (this file is a self-deleting file--so apparently it's not running as part of the installation). I'm guessing this custom action will need to be set to run immediately (and asynchronously) so that the batch file can execute and delete itself. Not sure how this may affect MSI's file tracking capability for "Repair" installations--need to research this some more. (Currently, the MSI is set to disable "Change" installation options functionality---I don't remember if this same setting disables "Repair" funcitonality. In any event, I would like to re-enable this functionality.)

I'm hoping I'll be able to push up an updated release.sh script later today.

[fourpastmidnight]

@dscho OK, finally pushed up a revised release.sh and created a make-file-list.sh script that's specific to creating the MSI. You can find it here.

As mentioned in the above post:

• The issue with git-bash.exe and git-cmd.exe not being installed has been resolved.
• Shortcuts are still not created, nor is the Start Menu folder.
• I haven't done anything with post-install.bat.
• This version of the installer script makes no provisions for an upgradeable Git MSI.

The next step is to resolve the shortcuts and Start Menu folder issues.

[fourpastmidnight]

@dscho I also managed to push up a revision to release.sh that creates a MSI installer with the Start Menu shortcuts for git-bash.exe, git-cmd.exe and git-gui.exe. It doesn't generate any MSI ICE (Internal Consistency Evaluation) errors or warnings. BUT, I haven't tested installing.

I'm wondering, also, if @robmen could take a quick look at this to double-check me on this---shortcuts can be a bit tricky.

The commit is here.

[fourpastmidnight]

The commit adding the Start Menu shortcuts is most probably not a good implementation. Yes, I get no ICE warnings/errors when generating the MSI, but it won't result in correct behavior for the shortcuts. I'm still trying to figure this out.

[fourpastmidnight]

@robmen: I'm attempting to fix the shortcuts in the MSI. I'm getting the "expected" ICE38, ICE43, and ICE57 errors (due to mixing per-machine and per-user concerns---which in this case can be safely ignored). However, I'm also getting ICE69 errors:

D:\Projects\GitForWindowsSDK\usr\src\build-extra\msi\GitComponents.wxs(19) : 
    warning LGHT1076 : 
        ICE69: Mismatched component reference. 
            Entry 'GitBash' of the Shortcut table belongs to component 
            'GitProgramShortcuts'. However, the formatted string in column 'Target' references
            file 'git_bash.exe' which belongs to component 'git_bash.exe'. 
            Components are in the same feature.

D:\Projects\GitForWindowsSDK\usr\src\build-extra\msi\GitComponents.wxs(25) : 
    warning LGHT1076 : 
        ICE69: Mismatched component reference. 
            Entry 'GitCMD' of the Shortcut table belongs to component 
            'GitProgramShortcuts'. However, the formatted string in column 'Target' references 
            file 'git_cmd.exe' which belongs to component 'git_cmd.exe'. 
            Components are in the same feature.

D:\Projects\GitForWindowsSDK\usr\src\build-extra\msi\GitComponents.wxs(31) : 
    warning LGHT1076 : 
        ICE69: Mismatched component reference. 
            Entry 'GitGUI' of the Shortcut table belongs to component 
            'GitProgramShortcuts'. However, the formatted string in column 'Target' references
            file 'git_gui.exe' which belongs to component 'git_gui.exe'. 
            Components are in the same feature.

Could not generate ./bin/Git-2.7.3.0-64-bit.msi

I followed the example at FireGiant. The major difference is I'm installing 3 shortcuts, not 1. Here's the relevant WiX code:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
    <Fragment>
        <ComponentGroup Id="GitComponents">
            .
            .
            .
            <Component Id="GitProgramShortcuts" Directory="GitProgramFolder">
                <Shortcut Id="GitBash"
                          Name="Git Bash"
                          Icon="git.ico"
                          Target="[#git_bash.exe]"
                          WorkingDirectory="WIX_DIR_PROFILE"
                          Arguments="--cd-to-home" />
                <Shortcut Id="GitCMD"
                          Name="Git CMD"
                          Icon="git.ico"
                          Target="[#git_cmd.exe]"
                          WorkingDirectory="WIX_DIR_PROFILE"
                          Arguments="--cd-to-home" />
                <Shortcut Id="GitGUI"
                          Name="Git GUI"
                          Icon="git.ico"
                          Target="[#git_gui.exe]"
                          WorkingDirectory="WIX_DIR_PROFILE" />
                <RemoveFolder Id="GitProgramFolder" On="uninstall" />
                <RegistryValue Root="HKLM"
                               Key="Software\GitForWindows"
                               Name="installed"
                               Type="integer"
                               Value="1"
                               KeyPath="yes" />
            </Component>
            .
            .
            .
            <Component Directory="INSTALLFOLDER:\cmd\">
                <File KeyPath="yes" Id="git_gui.exe" Source="cmd\git-gui.exe" />
            </Component>
            <Component Directory="INSTALLFOLDER">
                <File KeyPath="yes" Id="git_bash.exe" Source="git-bash.exe" />
            </Component>
            <Component Directory="INSTALLFOLDER">
                <File KeyPath="yes" Id="git_cmd.exe" Source="git-cmd.exe" />
            </Component>
            .
            .
            .
        </ComponentGroup>
    </Fragment>
</Wix>

I'll keep looking into it, but I'm really not understanding what the difference is or whether or not I can simply ignore this error.

[dscho]

@fourpastmidnight thank you so much, and sorry for my silence! Rest assured, I am very interested in your work, I just happen to be real busy elsewhere.

[fourpastmidnight]

@dscho no worries.

[fourpastmidnight]

@robmen I think I figured it all out.
@dscho After much research, I think I have successfully included Start Menu shortcuts for Git Bash, Git CMD, and Git GUI as part of the installer. I say "think" because I haven't yet tested the installer--though it does not generate any ICE errors or warnings at this point (I turned validation back on by removing the -sval command line switch that was passed to light.exe).

Before proceeding any further, I'm going to setup a virtual machine so I can test the installer as it currently is. You can find the commit here.

[robmen]

Sorry, I'm a bit dark until after March...

[fourpastmidnight]

@robmen No problem; didn't know how dark "dark" was going to be. Hope everything's going well.

[fourpastmidnight]

Just an update: I've been getting some virtual machines set up so I can test installers as I move forward. I will be taking into consideration all the feedback given thus far.

[fourpastmidnight]

Update: I tested the installer from the last commit I made on my branch. Here's what I found:

1. I logged the installation of the Git for Windows installer. post-install.bat does attempt to execute, but an error is encountered while it runs. The logs gave me some leads to look at to resolve the error(s).
2. Start Menu shortucts are properly created, per-machine, in the All User's Start Menu. I was able to modify a start menu shortcut (in this case, Git Bash) to "Run as Administrator" (hence how I discovered no permissions issues when running elevated).
3. The PATH environment variable is properly updated upon installation and removal.
4. I tried using a custom action supplied with WiX to set the Working Directory property of the Start Menu shortcuts. In native WiX (and MSI database, for that matter), you cannot set the Working Directory property to %HOMEDRIVE%%HOMEPATH%. It's not a valid value. The WixCA and corresponding WIX_DIR_PROFILE property evaluated to the installing user's home directory and path, hard coded (e.g. C:\User\Username). I'm going to need to research another way to do this. I have a few ideas.
5. Uninstalling generally worked. However, there were some files left behind. Specifically, files that were created post-install in /etc and /dev. Not a big deal--just need to add a component to ensure that the INSTALLDIR\ProgramFiles$(var.Bitness64)Folder\Git directory is removed on uninstall, even if files that weren't installed by the installer exist within those folders.

Other than that, this installer works as well as I had expected it to! Which is great! I feel, as far as the MSI in and of itself is concerned, that this effort is on a very good trajectory.

Next Steps:

• Resolve the issue of left behind files.
• Do more research and/or attempt to resolve the Start Menu shortcut Working Directory property value.
• Look into the error(s) that occur while executing post-install.bat.

[dscho]

I logged the installation of the Git for Windows installer. post-install.bat does attempt to execute, but an error is encountered while it runs. The logs gave me some leads to look at to resolve the error(s).

Oh, nice. Is the error a secret, or can you share it with us?

I tried using a custom action supplied with WiX to set the Working Directory property of the Start Menu shortcuts.

Why not just use the --cd-to-home option of both git-cmd.exe and git-bash.exe?

Uninstalling generally worked. However, there were some files left behind.

Maybe we can add a custom uninstall action? I feel that removing the entire directory wholesale, including files that might have been added by third-party installers, is the inappropriate thing to do.

[fourpastmidnight]

Things are progressing slowly. I have definitely made progress--but I only get about an hour a night during the week to work on this. I have a few kinks to work out, and then some broader cleanup and other stuff to do. I expect it'll be a little while yet before I have anything new to show. But things are looking good and I'm excited to see the end result.

[dscho]

Thanks for keeping the ball going!

[fourpastmidnight]

So, I've been looking into turning some of the installer "options" into full-fledged MSI Features. What does this give us? It gives us the ability to use the installer to change/modify the current installation, such as changing the PATH environment setting after installation (without having to do it manually, which on Windows 10, can actually be harder than it needs to be).

One of the other major potential benefits I was hoping to achieve with this work was being able to later choose the Terminal Host option (e.g. MinTTY vs. Command Prompt). Unfortunately, this is not possible. This is because there's only one executable, git-bash.exe, and we edit that file's string table resources in order to run bash in a Console Host hosted terminal (e.g. standard windows command prompt-type terminal) vs. a MinTTY terminal. With an MSI, if two separate Features include the same Component, then when uninstalling one Feature and installing the other will not result in uninstalling the existing git-bash.exe component and "re-installing" git-bash.exe (the terminal hosting features are mutually exclusive).

Further complicating things is that once you edit the string resources using edit-git-bash.exe, there's no way to go back. So the long ad short is, using MSI Features to control whether MinTTY or ConHost is used as the terminal host is not possible. This stinks, but there may be an alternative.

On my radar has been modifying edit-git-bash.exe such that the switch from MinTTY to ConHost is no longer one-way. Instead of providing a new "command line" to update which terminal host hosts bash, you would instead specify which terminal host to use, e.g.:

# The second argument would be case-insensitive
$ ./edit-git-bash.exe git-bash.exe MinTTY
# -- OR --
$ ./edit-git-bash.exe git-bash.exe CmdPrompt

This provides two benefits: for those who wish to use the MSI to change their installation, they can switch between MinTTY and ConHost. But also, since edit-git-bash.exe is no longer performing a one-way transformation on git-bash.exe, there's no reason to not simply install edit-git-bash.exe (even with InnoSetup or the portable distribution) so that a user can run it anytime they want to change the terminal host.

@dscho I know that you mentioned that you wanted to just install this executable anyway (I believe you said in /mingw64/share/git?). I propose we do just that. I also propose that the name of edit-git-bash.exe be changed to something like set-git-bash-terminal.exe or something similar.

Any thoughts?

[mfriedrich74]

What stops you from using two components and use one or the other depending on the selected feature? You would need to prepare the two executables upfront to include both binaries in the MSI.

[fourpastmidnight]

There is only one executable, thus one component, hence why using a MSI Feature for terminal host selection won't work (based on the installed executable). But, I did just get an idea that might make this work.

I can use a registry entry as the keypath component for the "Features". I already have a custom action that executes edit-git-bash.exe. Depending on the installed "Feature", I execute the custom action accordingly, appropriately modifying git-bash.exe so that the selected terminal host is used.

@dscho I was able to modify edit-git-bash.exe so that it can now switch git-bash.exe back and forth to use either MinTTY or ConsoleHost at your whim. I'll put up a PR tomorrow.

[fourpastmidnight]

OK, as I said this morning, I was able to modify edit-git-bash.exe so that it can switch git-bash.exe between using either MinTTY or ConsoleHost.

However, while investigating this more, I determined that git-bash.exe already contains 2 string resources: the first being the command line to use to invoke MinTTY as the terminal host for Git BASH; the second being the command line to use to invoke ConsoleHost as the terminal host for Git BASH.

So I haven't pushed up a PR because I'm going to push up 2 PRs, but the second one is not ready yet. The second PR will allow edit-git-bash.exe to simply "swap" the string resources in order to change the "active terminal host". (That statement is a bit of an over-simplification.) The benefit to this design is that now edit-git-bash.exe doesn't even need to know the command line invocations to be used. It'll simply use the existing invocations that are already part of git-bash.exe. This is nice because I just noticed that as of August of this year, those string resources have in fact changed--so this reduces the number of places in which these changes need to be made. (The first modification I made which I alluded to previously, stored the command lines in edit-git-bash.exe.)

I need to refactor this second approach before pushing it up. But, I want to push up both versions and see which one sticks.

[dscho]

However, while investigating this more, I determined that git-bash.exe already contains 2 string resources: the first being the command line to use to invoke MinTTY as the terminal host for Git BASH; the second being the command line to use to invoke ConsoleHost as the terminal host for Git BASH.

@fourpastmidnight sorry for not coming back earlier... busy as always, is my only excuse.

The reason that there are 2 string resources: when mintty.exe cannot be launched, the idea is that git-bash.exe falls back to the CMD version.

I just tested and verified that this is indeed still the case.

So one other way you could address this issue is by simply moving the usr\bin\mintty.exe into a "MinTTY" component...

[fourpastmidnight]

Sorry for the delay in getting the PRs up for edit-git-bash.exe; I got pretty sick last week and have only been able to dedicate an hour here or there. I just finished refactoring the new code; it compiles, but after the refactor, I need to retest to make sure I didn't break anything. Hopefully I can get the PR up early this weekend at the latest.

[fourpastmidnight]

@dscho Sorry, just saw your comment...hmmmm. OK. Darn, I thought it would be nice to be able to switch back and forth between terminal hosts.

Ah, I see where you're going. Creating an explicit "MinTTY" component: it's only installed if MinTTY is selected as the terminal choice; so, if the user chooses ConHost, MinTTY.exe is not installed, and we get the desired behavior. Hmm, cool. And that means that we don't need edit-git-bash.exe at all. I rather like that better. I guess I didn't see the code (or didn't understand what I was seeing) related to the "fallback" mechanism there.

OK, let me work on that. If this works for the MSI, it should also be possible to implement in the InnoSetup installer, too.

[dscho]

@fourpastmidnight thank you!

[dscho]

@fourpastmidnight thank you for sticking with this!

[fourpastmidnight]

@dscho So, with that bit of insight, edit-git-bash.exe is not required by the MSI to use the Windows Console host as the terminal host for Git for Windows' BASH shell--it's simply as you said, without mintty.exe being present, git-bash.exe falls back to using the Windows Console Host. This means that with the MSI, a user can modify their Git for Windows installation to switch back and forth between using MinTTY or Windows Console Host as the terminal for Git for Windows' BASH shell.

[dscho]

Nice!

[fourpastmidnight]

It's been a long while since I've commented here. First there were the holidays. Then there was my family and I getting over various illnesses. But, I'm happy to report that we're all doing well. I'm also happy to report that over the last week, I've made significant progress. Unfortunately, my repo is a mess as I tried various approaches to achieve a quality installer.

I have vastly reconfigured the MSI to use MSI Features wherever possible and wherever it made sense to do so. The only thing I have left to finish is having the installer allow the user to choose to create desktop shortcuts for the various Git for Windows executables.

I also see that recently, there was a new option added to allow users to turn on the experimental diff built-in. So I'll need to add support for this--but fortunately, since I have everything else completed, this will fall into a similar pattern as enabling Git Credentials Manager for Windows or Git FsCache, so this won't take very long at all.

My next steps are to:

• Finish up support for desktop shortcuts
• Clean up some of the feature logic
• Add support for enabling core.symlinks
• Add the option to configure Git for Windows to use the new experimental diff built-in
• Look into supporting selecting PuTTY as the SSH client as per the InnoSetup installer
• Clean up the branch
  • This will essentially undo a lot of PR 125 that's still "on hold". I will eventually close this PR.
• Submit a new PR

I expect this will take me a bit of time yet--but I just wanted to report in. While completing the above steps will complete most of the obvious functional aspects of the installer, there's still quite a bit of overall testing that I need to perform before I would feel comfortable giving this the green light. However, I am closer than ever and I'm really excited to have gotten to this point in this project.

[dscho]

I also see that recently, there was a new option added to allow users to turn on the experimental diff built-in.

Please do not worry about that. Upstream Git already accepted the builtin difftool, therefore the opt-in will go away.

However, I am closer than ever and I'm really excited to have gotten to this point in this project.

Great!!!

[fourpastmidnight]

Upstream Git already accepted the builtin difftool...

That's great news.

[fourpastmidnight]

As of tonight, I have finished the bulk of the implementation of all MSI Git for Windows Features for an installation. I have some minor bug fixes to look into with respect to changing an installation of Git for Windows, and some overall cleanup that I want to do in order to better organize the files; but other than that, I'm wrapping up development.

Once I wrap up these items, I'll be submitting a PR. There will most likely be a few PRs following the initial PR to further refine the implementation to ensure that I'm "following all the [MSI] rules".

While submitting the PR will, I'm sure, be welcome news, there is still quite a bit of work to be done before we can begin distributing Git for Windows via MSI. For example, I need to research a few more things like the Files in Use (Restart Manager) dialog and determine whether this should be implemented, which I believe, would help avoid the issue that caused me to begin picking up the work on an MSI to begin with.

Then there's a heavy round of testing that needs to occur. Testing that all the various modification scenarios work. Testing that administrative and unattended installations work (this will aid corporate deployment via GPO, for example). Once this heavy round of testing is done, then there's research into MSI versioning and ProductCode requirements and possible pursuant conversations that may come out of that research.

But I am very much on the home stretch now. I know I said this about 8 months ago, but who would've thought one little comment on a PR back in June would lead to such a dramatic change in the implementation--a hard change, but a change for the better.

[dscho]

Good work!

[jcasale]

@fourpastmidnight are you still planning on releasing your work? Any chance to make your current progress public?

[dscho]

Seeing as this has not seen much progress, combined with the fact that MSI does not support LZMA compression (and last time I checked, it also had no support for SHA-256 code-signing, only for now-considered-insecure SHA-1), I'll close this.

[mfriedrich74]

SHA 2 is supported of course. Try either mszip with no compression an let burn do the job, or try mszip with high setting. (Windows installer xml)

…

On Wed, Jan 1, 2020, 1:14 PM Johannes Schindelin ***@***.***> wrote: Seeing as this has not seen much progress, combined with the fact that MSI does not support LZMA compression (and last time I checked, it also had no support for SHA-256 code-signing, only for now-considered-insecure SHA-1), I'll close this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#682?email_source=notifications&email_token=ABZH5SHARJFSJ4G4G44AYBTQ3TMPDA5CNFSM4B47O43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5J22I#issuecomment-570072425>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZH5SBVIYWN6NO3RPWCALTQ3TMPDANCNFSM4B47O43A> .

[dscho]

SHA 2 is supported of course. Try either mszip with no compression an let burn do the job, or try mszip with high setting.

I won't try. If you are interested, you can do that, @mfriedrich74. I have enough on my plate already, thank you very much.

[mfriedrich74]

Dito.

…

On Thu, Jan 2, 2020, 2:01 PM Johannes Schindelin ***@***.***> wrote: SHA 2 is supported of course. Try either mszip with no compression an let burn do the job, or try mszip with high setting. I won't try. If you are interested, you can do that, @mfriedrich74 <https://github.com/mfriedrich74>. I have enough on my plate already, thank you very much. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#682?email_source=notifications&email_token=ABZH5SHRHJZ5IUFOFK47RFLQ3Y2Y5A5CNFSM4B47O43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH7DF7A#issuecomment-570307324>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZH5SHFPQOPQNVHNHG5WWLQ3Y2Y5ANCNFSM4B47O43A> .

[robmen]

@dscho I appreciate that you manage the Git integrations and provide a release of just the git binaries with every release. That allows me to maintain the clean and simple gitsetup project that works much as @mfriedrich74 requests.

Keep up the great work. 🎉

[dscho]

@robmen thank you!

Would you prefer to keep the gitsetup project in its own tree? In that case, I would probably want to delete the msi/ subdirectory from the build-extra repository.

Alternatively, would you be interested in updating the msi/ subdirectory to reflect your current gitsetup?

[robmen]

Meh. Last time I started integrating my work, it took on a life of its own as people tried to turn it into everything for everyone. I just want something really simple and streamlined. I'd be happy to see that be delivered by git-for-windows proper (it would save me doing updates) but I don't have the cycles to make it happen (since doing updates aren't that expensive for me in gitsetup at this point).

Do as you wish, @dscho. 😄

[dscho]

Do as you wish, @dscho. 😄

I'll leave everything as-is, for the time being ;-)