git 🚀 - Installer does not roll back properly

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?

dscho on 3 Mar 2016

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.

fourpastmidnight on 4 Mar 2016

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?

dscho on 5 Mar 2016

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 on 5 Mar 2016

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.

fourpastmidnight on 5 Mar 2016

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: https://github.com/git-for-windows/build-extra/pull/96#issuecomment-177232211

dscho on 6 Mar 2016

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.

fourpastmidnight on 6 Mar 2016

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.

dscho on 7 Mar 2016

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.

robmen on 8 Mar 2016

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:

Generating the WiX component *.wxs file(s) and check it/them for correctness
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
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
Tidy up any loose ends
- I'm hoping by this step, if not 3 above, we'll have a release-ready MSI installer
(Optional) Implement any desired setup enhancements, E.g. ability to not install Git-GUI if you don't want it, or any other enhancements.

fourpastmidnight on 9 Mar 2016

@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)?

dscho on 9 Mar 2016

@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?

fourpastmidnight on 9 Mar 2016

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

Yep.

dscho on 9 Mar 2016

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.

fourpastmidnight on 10 Mar 2016

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

dscho on 10 Mar 2016

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 on 12 Mar 2016

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 on 13 Mar 2016

@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 on 14 Mar 2016

@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 on 14 Mar 2016

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 on 15 Mar 2016

@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.

fourpastmidnight on 15 Mar 2016

@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.

dscho on 15 Mar 2016

@dscho no worries.

fourpastmidnight on 16 Mar 2016

@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.

fourpastmidnight on 16 Mar 2016

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

robmen on 16 Mar 2016

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

fourpastmidnight on 17 Mar 2016

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 on 22 Mar 2016

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

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).
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).
The PATH environment variable is properly updated upon installation and removal.
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.
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.

fourpastmidnight on 23 Mar 2016

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.

dscho on 23 Mar 2016

Oh, nice. Is the error a secret, or can you share it with us?
I'll post the relevant section of the log file later today. It's a file permissions issue; but that error could also mean several things, such as the file was locked when modification was attempted. Anyway, I'll update this issue with the info.

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

I am already doing that. I was just copying (admittedly, cargo-cult style in this case) what I witnessed as the result of the existing InnoSoft Setup installer when the shortcuts were created. If the --cd-to-home argument is enough, then this is a non-issue.

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.

There's only one installer running, Git for Window. If the files are in the program files directory, then upon uninstallation, they should be removed. Otherwise, those files belong elsewhere, such as in C:\ProgramData\Git (for system-wide settings) or in a per-user location for user-specific settings.

The files that were left behind were the ones in /dev and a few in /etc folders of the C:\Program Files\Git installation folder, such as fd, mtab and hosts. These should be removed if one completely uninstalls Git for Windows from their machine.

One of the most annoying aspects of incorrect installers are those that leave stray, useless files polluting the filesystem and Windows Registry (the files are useless once the program that uses them is no longer installed). When I remove a program, with the exception of (possibly) user-setting data (in case I decide to reinstall), I want no trace of the program left on my computer.

In this case, it's just an oversight in the authoring of the installer. I've seen How-Tos in the WiX documentation on how to accomplish this--it's a perfectly normal thing to find when developing an installer with a well-known solution (I just don't know it off the top of my head).

fourpastmidnight on 23 Mar 2016

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.

There's only one installer running, Git for Window. If the files are in the program files directory, then upon uninstallation, they should be removed. Otherwise, those files belong elsewhere, such as in C:\ProgramData\Git (for system-wide settings) or in a per-user location for user-specific settings.

That is not always possible. Take credential helpers, for example. Or third-party remote helpers. They need to be _somewhere_ on the PATH visible from Git for Windows. The only appropriate place for that is in C:\Program Files\Git\mingw64\libexec\git-core (or the 32-bit equivalent).

Assuming that it is okay to uninstall them is incorrect.

The files that were left behind were the ones in /dev and a few in /etc folders of the C:\Program Files\Git installation folder, such as fd, mtab and hosts. These should be removed if one completely uninstalls Git for Windows from their machine.

Agreed. We _know_ that those files are installed by us, though. That is why it is appropriate to remove them upon uninstallation.

dscho on 23 Mar 2016

That is not always possible. Take credential helpers, for example. Or third-party remote helpers. They need to be somewhere on the PATH visible from Git for Windows. The only appropriate place for that is in C:\Program Files\Gitmingw64\libexec\git-core (or the 32-bit equivalent).

That's a good point you make. I would argue, then, that the git-credential-manager should be handled as a "bundled" install--meaing, it's distributed and installed (by default, unless unselected) with Git, but it should be it's own installation outright (in its own filesystem location independent of git--after all, you don't _need_ git-credential-manager, but it's awfully nice to have), putting itself on the PATH so git and other programs can easily invoke its services. This avoids the whole complication about what should/shouldn't be uninstalled. This provides a much cleaner install/uninstall scenario for the end-user.

fourpastmidnight on 23 Mar 2016

Unfortunately, it is already practice by some third-party installers to reuse our path... So I guess we have to work with it.

dscho on 23 Mar 2016

I was just looking over the Git Credential Manager for Windows repo. I guess you're right. Well then, scratch that item off the list. ;)

fourpastmidnight on 24 Mar 2016

Here's that MSI log where the Custom Action executes the post-install.bat file:

MSI (s) (C4:04) [00:28:35:307]: Executing op: ActionStart(Name=ExecPostInstallBat,,)
MSI (s) (C4:04) [00:28:35:526]: Executing op: CustomActionSchedule(Action=ExecPostInstallBat,ActionType=3137,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\Windows\system32\cmd.exe" /c "C:\Program Files\Git\post-install.bat")
MSI (s) (C4:34) [00:28:35:651]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI363B.tmp, Entrypoint: WixQuietExec64
MSI (s) (C4:0C) [00:28:35:885]: Generating random cookie.
MSI (s) (C4:0C) [00:28:36:167]: Created Custom Action Server with PID 3028 (0xBD4).
MSI (s) (C4:C4) [00:28:38:167]: Running as a service.
MSI (s) (C4:C4) [00:28:38:432]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
WixQuietExec64:  mkdir: cannot change permissions of '/dev/shm': Permission denied
WixQuietExec64:  mkdir: cannot change permissions of '/dev/mqueue': Permission denied
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\hosts' -> '/etc/hosts'
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\protocol' -> '/etc/protocols'
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\services' -> '/etc/services'
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\networks' -> '/etc/networks'
WixQuietExec64:  The batch file cannot be found.
WixQuietExec64:  Error 0x80070001: Command line returned an error.
WixQuietExec64:  Error 0x80070001: QuietExec64 Failed
WixQuietExec64:  Error 0x80070001: Failed in ExecCommon method
CustomAction ExecPostInstallBat returned actual error code 1603 but will be translated to success due to continue marking

Now, the line where it says The batch file cannot be found. I'm fairly certain has nothing to do with the error at hand and that this line is here because the post-install.bat file deletes itself. (I also believe this may be the cause of those Error 0x80070001 lines.) I believe these two lines, however, are what I need to focus my attention on for resolving the issue:

WixQuietExec64:  mkdir: cannot change permissions of '/dev/shm': Permission denied
WixQuietExec64:  mkdir: cannot change permissions of '/dev/mqueue': Permission denied

I tried changing some things in the installer, such as user impersonation, deferred vs. immediate execution, when it's scheduled to run, etc,, all to no avail--either light.exe complained about mis-authoring of the MSI (i.e. ICE violations) or the installer worked no better or worse than it had before, producing the same log output.

fourpastmidnight on 24 Mar 2016

Now, the line where it says The batch file cannot be found.

That's easily explained: the post-install.bat script is supposed to delete itself, similar to Mission Impossible's mission descriptions.

WixQuietExec64: mkdir: cannot change permissions of '/dev/shm': Permission denied
WixQuietExec64: mkdir: cannot change permissions of '/dev/mqueue': Permission denied

Those two are expected. As I hinted earlier, the POSIX permission system assumed by the mkdir command (it tries to execute mkdir -m1777 /dev/shm) is simply incompatible with Windows' ACLs, same for /dev/mqueue/. It is no use to create the directories manually, though, because the same init script (provided by MSYS2, so it is a bit funny why they insist on the 1777 permission) will try to chmod 1777 /dev/shm if that directory already exists.

So I think we will have to live with that message.

What we do _not_ have to live with is that the /etc/post-install/*.post scripts _run again_ after installation. The purpose of the post-install.bat script is to run those scripts, including 99-post-install-cleanup.post which is supposed to just nuke all of the /etc/post-install/*.post scripts.

And that is _exactly_ where things go wrong. The 99-post-install-cleanup.pots script reads thusly:

# Only remove post-install scripts if we're not in the SDK.
# They need to be there to build the installer packages.
if [ -f /ReleaseNotes.html -o -f /README.portable ]
then
  rm -rf /etc/post-install
fi

The idea is that this file is _not_ allowed to nuke _anything_ when run in the SDK. Because if it does, then the files are gone by the time when we need to include them in the installer!

That means that we have to come up with a way to tell that we're not in the SDK, e.g. by including the ReleaseNotes.html file (which we should do anyway, because the official Git for Windows installer includes said file, too).

dscho on 24 Mar 2016

Here's that MSI log

@fourpastmidnight could you please educate me where I can find that log?

dscho on 24 Mar 2016

@dscho: The portion of the log I posted above is the only portion of the 11MB log file that's relevant. Everything else worked as expected. But, I've attached it for you.

Thanks for the explanations above. I'll look into authoring the ReleaseNotes.html file into the MSI--it was on my list of things to do, I just didn't realize it played a "critical" role in the installation.
Git_Install-verbose.log.txt

fourpastmidnight on 25 Mar 2016

@dscho: I authored in the RealeaseNotes.html file and "magical" things happened:

post-install.bat ran, and /etc/post-install/ was removed during installation.
While there are still those error messages in the MSI log re: /dev/shm and /dev/mqueue (which as has been noted is expected), those errors are no longer present when starting Git Bash after installation--presumably because the various /etc/post-install/*-post-install*.post files got executed due to the presence of ReleaseNotes.html.

To recap where we are:

The installer installs Git for Windows per-machine.
The installer correctly copies all Git for Windows files, including
- git-bash.exe
- git-cmd.exe, and
- git-gui.exe
The installer correctly installs Start Menu shortcuts in the per-machine Start Menu in a Git folder.
ReleaseNotes.html is installed in the main installation directory.
- As a result of this, the /etc/post-install/*-post-install*.post scripts are executed and removed.
- It appears the various /dev files/folders get their permissions set correctly, so no more errors appear when starting Git Bash.
- NOTE: A Start Menu shortcut is not created for this file. Do you want one created for it?
The installer appropriately modifies the system PATH environment variable on installation and uninstallation.
The installer creates the appropriate Windows registry entries in HKLM\SOFTWARE\GitForWindows.
- That's not to say that all required entries are created--just the ones that are necessarily required for clean installation/uninstallation by msiexec. For example, the InnoSetup installer creates an entry called LibExecPath. This is not yet authored into the installer.

I'll try to get the latest changes pushed up as soon as I have a chance. The next few days are going to be a bit busy for me.

After I get these changes pushed up, I'll begin to work on filling in the details by pouring over the InnoSetup scripts. At the same time, I'll be making note of the various UI requirements (e.g. implementing the ability to choose the console window to use, CRLF options, etc.).

There's still quite a bit of work ahead, but significant progress has been made.

fourpastmidnight on 25 Mar 2016

The portion of the log I posted above is the only portion of the 11MB log file that's relevant.

Whoops. I meant to ask instead: where can I find the log _in my setup_? (I am really a noob when it comes to MSI installers...).

BTW great progress, and thanks so much for your detailed write-up.

FWIW the DisplayVersion registry entry is more important than the LibExecPath entry, as the former is used by third-party software to determine whether Git for Windows is installed or not.

dscho on 25 Mar 2016

@dscho: You have to run msiexec from the command line:

C:\> msiexec /i {package_name.msi} /l[log_options] {path\to\logfile.log}

Here are the options to /l:

Logging Options
    /l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] <LogFile>
        i - Status messages
        w - Nonfatal warnings
        e - All error messages
        a - Start up of actions
        r - Action-specific records
        u - User requests
        c - Initial UI parameters
        m - Out-of-memory or fatal exit information
        o - Out-of-disk-space messages
        p - Terminal properties
        v - Verbose output
        x - Extra debugging information
        + - Append to existing log file
        ! - Flush each line to the log
        * - Log all information, except for v and x options
    /log <LogFile>
        Equivalent of /l* <LogFile>

/l*v! produces that 11MB monstrosity in this case ;). I found that /lier! worked well enough. You only need the heavy duty verobsity when you have a real stumper of a problem. You can find all the other available options via msiexec /?.

I'll be sure to include that Registry value; thanks for the heads-up.

fourpastmidnight on 25 Mar 2016

@dscho: I found some time to push up my latest changes of the working MSI installer. As I said, there's still a lot of work to be done yet. I hope my commits are more fine-grained for you this time, with better explanations of the changes that were made.

fourpastmidnight on 26 Mar 2016

@fourpastmidnight thanks! How about opening a Pull Request? That way I can keep better track of the iterations and can help more efficiently...

dscho on 28 Mar 2016

You have to run msiexec from the command line:

C:\> msiexec /i {package_name.msi} /l[log_options] {path\to\logfile.log}

@fourpastmidnight thanks!

dscho on 28 Mar 2016

Sorry, been busy with work the past couple of days. I hope to get back to work on this over the weekend.

fourpastmidnight on 31 Mar 2016

@fourpastmidnight no worries, I am really glad that you are giving the MSI installer some love.

dscho on 1 Apr 2016

Just checking in--I am making some slow progress on the UI front. I'm just taking it slow, making sure I account for everything that needs to be accounted for.

fourpastmidnight on 5 Apr 2016

Checking in--I've been working on this every night and on weekends. I'm getting into the "finer" details of the installer and it's just been slower going than it was when I first started this. Things are coming along and I hope to have some progress to show soon.

fourpastmidnight on 20 Apr 2016

Thanks for the update!

dscho on 20 Apr 2016

I've rolled up the minimal set of changes to address the feedback at the bottom of git-for-windows/build-extra#96 with PR: git-for-windows/build-extra#112.

If 112 looks good, it'd be awesome to break down any remaining work @dscho wants completed into smaller issues so we can effectively divide and conquer.

robmen on 21 Apr 2016

@robmen Glad to see you back. I have a fork over on my GitHub. I haven't created a pull request yet and it's not current with my local workspace. I've been at work on the UI, but I haven't committed anything yet.

However, it's at a point where I have two more pieces of UI functionality to complete, and then we get to the hard stuff (for me, anyway): Implementing the "setup options" for reinstall/repair/update scenarios. IOW, having the right conditions on the Git For Windows-specific dialogs to behave correctly for various supported installation modes.

So I'm going to pause, get my local repo cleaned up and commit and push what I have completed. Then I'll update my branch with master and issue a pull request. (The latest major change that impacts the installer that I have seen is the inclusion of Git Credential Manager for Windows--and I have no UI support for it yet, but I don't anticipate any complications adding that support.)

Once I issue a pull request, I'll outline where I am and what I believe is still outstanding. Then we can evaluate the current state of affairs and determine how to proceed.

fourpastmidnight on 21 Apr 2016

@fourpastmidnight if I promise not to judge you on the quality of a topic branch that is in flight, would you mind committing early and often and opening a [DO NOT MERGE YET] Pull Request?

For the record: I frequently to the same, committing a lot of fixup! commits (and sometimes, when I run out of time, I simply commit _everything_ at the end of the day in one huge messy commit with the commit message "wip" and push, just so I have a backup and a known state of affairs).

dscho on 21 Apr 2016

100% agreed.

Also, smaller issues to tackle would help as well. Right now we're looking at potential convoy problems.

robmen on 21 Apr 2016

@dscho: Deal. It's very rough and needs a lot of cleanup, but most of the "heavy-lifting" is done.

Question for you: In order to implement allowing the user to choose PuTTY as the default SSH client (#462), I needed to create two MSI custom actions (they only read system state, @robmen <grin />). I wrote them in C++ and they require that at least the Windows SDK for Vista (or above) be installed to compile the custom actions.

So, having said that, I don't really think this fits into the Git for Windows SDK development workflow. It's not an insignificant dependency and I'm not sure we want this dependency. Let me know if you agree. If so, I won't even bother committing this work and we can close #462 (or keep it closed if it already is--I forget it's current status).

Lastly, I won't get to this until later tonight.

fourpastmidnight on 21 Apr 2016

@dscho, @robmen I created PR113.

You can read through the commit messages (especially for this commit).

The main takeaways are:

You can run release.sh and build the MSI
You can run the MSI to install Git for Windows
Even though the installer asks for your preferences for line endings, command line environment, etc., it's not _doing anything_ with those user preferences yet.
- On the plus side, I've built in support for the installer to "remember" those preferences on reinstall, repair, and upgrade of Git for Windows
- The UI still needs to be updated to properly support reinstall, repair, and upgrade scenarios, though.
Git Credential Manager For Windows is not supported--but that support won't be hard to include.
I decided to leave out all the PuTTY stuff, because I'm not so sure it fits. But, I have all the code and dialogs.
- It might be worth me splitting off another branch that includes the PuTTY stuff if you're really interested. But with the dependency on the Windows SDK--I'm not so sure it fits. Let me know.

fourpastmidnight on 22 Apr 2016

Thanks!

dscho on 22 Apr 2016

One more thing I forgot to mention in the commit comments regarding the UI (I can update the pull request notes, too):

Some of the custom dialogs for git options are arranged so that the dialogs will work with accessibility devices (e.g. screen readers). I have to admit, though, that I haven't tested these dialogs with such assistive technology yet, as I had pretty much only yesterday (technically, it's 3am, so it would be two days ago) wrapped up what you see in that Pull Request.

Alright, I'm off to get what little sleep I can get before I need to wake up for work today!

fourpastmidnight on 22 Apr 2016

@fourpastmidnight cool to see the UI started. I dislike dealing with MSI UI so I'm glad you've got the bulk of it started there. You might try rebasing off git-for-windows/build-extra#112 since that will get you the minimal MSI that installs Git properly.

robmen on 22 Apr 2016

@fourpastmidnight I'd like to merge git-for-windows/build-extra#112 because it is so well-contained, any objections?

dscho on 22 Apr 2016

Well, I guess that sounds good to me; @robmen is pretty much _the man_ when it comes to installers.. I'm just happy to be able to contribute and learn.

fourpastmidnight on 22 Apr 2016

Merged it.

dscho on 22 Apr 2016

@robmen, I could try rebasing off of PR112--though I'm not sure how I would do that on GitHub... I'm a bit new to this platform and haven't contributed much to other open source projects.

Also, because I've effectively "shared" my branch, is it ok for me to do a rebase?

Oh, and @dscho, sorry, I forgot to "sign-off" my PR. But when the final PR is ready, I'll try to remember to do that (or I'm sure you'll slap my wrist... ;) j/k ).

fourpastmidnight on 22 Apr 2016

Or, I could try rebasing off of the merge that just happened ;) -- that is, if rebasing is alright.

fourpastmidnight on 22 Apr 2016

Also, because I've effectively "shared" my branch, is it ok for me to do a rebase?

Absolutely. Pull Requests are based on branches with the intention of rewriting the branches until they are good to be merged.

Rebasing is alright!

dscho on 22 Apr 2016

Thanks!! That's why I haven't done any rebasing to fix the "divergence" of my branch--I wasn't sure if that was OK.

With that, then, I could also add the support for the Git Credentials Manager for Windows, too.

fourpastmidnight on 22 Apr 2016

It's absolutely okay. As the original author of the interactive rebase, I would also be delighted if you used that tool :-)

dscho on 22 Apr 2016

@dscho: qq -- after rebasing, when I want to push the rebased branch, do I have to do a forced push?

fourpastmidnight on 22 Apr 2016

Yes, you will have to force the push (I usually call git push my-remote +HEAD) because you want GitHub to forget the exact commits you had before, and GitHub does not like to forget without you asking it explicitly to do so. :smile:

dscho on 22 Apr 2016

@dscho: Ok, that's what I thought. Thanks for the tips!!

I found a good write-up on git-rebase --interactive -- I see why you want me to use it :) There are a few commit messages I wouldn't mind rewording/adding to anyway to make it more clear what's in the commit.

I'll work on getting my branch current and repush it up and issue a new pull request(?) later on tonight.

Hopefully I can continue to push this forward over the weekend.

@robmen: let me know if you're taking anything on or if there's anything you see in my work that needs to change so we don't step on each other's toes. I see a light at the end of the tunnel and I'm excited that we have gotten this far.

fourpastmidnight on 22 Apr 2016

Instead of a new PR, just force-push the branch; it will update the Pull Request automagically.

dscho on 22 Apr 2016

I found a good write-up on git-rebase --interactive

That is really a nice write-up. I linked to it in our _How to participate_ wiki page.

dscho on 22 Apr 2016

@dscho: Not terribly important, but when you have a minute, I'd appreciate any comments/thoughts you have on what I've done towards #462 and whether or not you feel that fits well with Git for Windows long-term.

I'm leaning towards let's not do it due to the dependency on the Windows SDK. Also, as I've already mentioned, there's a lot of information online that's available that shows how to setup Git for Windows to use PuTTY if someone really wants to do that. So I'm not really sure that we need to concern ourselves with that. Git for Windows provides a solution out of the box via OpenSSH. And with the recent inclusion of Git Credentials Manager for Windows, the UX is _really nice_. (I've been using it on my work laptop and the UX is _seamless_ and _completely transparent_. I love it!)

fourpastmidnight on 22 Apr 2016

😄1

Instead of a new PR, just force-push the branch; it will update the Pull Request automagically.

Be sure to leave a comment mentioning it afterward, however, because it was mentioned in another PR that dscho won't get notified automatically when the branch is re-pushed.

landstander668 on 22 Apr 2016

@fourpastmidnight I'm not going to take a position on whether or not the use of PuTTY should be retained as an alternative to OpenSSH. For what it's worth, however, ssh-pageant support was recently integrated and should be present in the next release. This lets OpenSSH transparently use Pageant (the PuTTY authentication agent) in place of ssh-agent for key-based authentication.

I suspect that key management was a _big_ driver for people wanting/needing to use PuTTY. If so, this should the switch to using OpenSSH relatively painless.

landstander668 on 22 Apr 2016

@landstander668 Even more reason to not bother messing with supporting (per se) PuTTY in the installer itself the way it used to--you already have a solution that will "bridge that gap".

Having said that, though, will there be any installer support needed for your solution in order to configure Git for Windows to use this "bridge", or is this simple enough that a user can configure this post-installation? Perhaps a better question is, has the current InnoSetup installer been modified to support this? If the answer is yes, then the MSI needs to follow suit.

fourpastmidnight on 22 Apr 2016

@robmen I was really scratching my head on how to get the user's "personal folder" for the working directory for a _per-machine_ installation! I couldn't get around those ICE errors. This solution is genius! OK, you just happen to know a lot more about MSI than I do, but this is something I've wondered about for a _long_ time over the years. I'm glad I finally know how to do this.

fourpastmidnight on 23 Apr 2016

@robmen Reading over the documentation, though, I see a potential problem with this solution. Won't this result in the Start menu shortcuts for a _per-machine_ installation having their Working Directory set to the installing user's home directory (e.g. C:\Users\installing_user)? If so, doesn't that also imply that for _all users_ on the machine who wish to use Git for Windows, the Working Directory will be pointing to the installing user's home directory, and not the logged on user's home directory? If this is the case, this could be problematic since in most (read almost all) environments, users don't have access to one another's home directories.

In which case, would it then be better to author the shortcuts the way I had authored them over on my branch (since it uses the --cd-to-home command line switch of git-bash.exe in the Arguments field of the shortcut)?

fourpastmidnight on 23 Apr 2016

@robmen: I just built the installer based off of master and installed it onto my test VM. Setting the shortcut working directory to PersonalFolder inside of the WiX XML will result in the Start menu shortcuts for Git Bash and Git CMD having a working folder set to the installing user's "My Documents" folder (C:\Users\GfwUser\Documents is the path Working Directory was set to on my test VM).

Furthermore, when I created a second user on this machine (with non-admin privileges) called GfwUser2 and switched to that user, the Working Directory for the shortcut still remained C:\Users\GfwUser\Documents as I suspected it would. And when starting Git Bash, because GfwUser2 doesn't have access to GfwUser's personal folder, Git Bash's working directory becomes C:\Windows\System32, which is what we don't want.

All in all, unfortunately, the use of PersonalFolder is not having the desired outcome. However, the shortcuts that I authored do work properly and also present no ICE validation errors upon building the MSI. They don't attempt to set the working directory and rely on setting the Argument property of the shortcuts to use the option --cd-to-home which makes sure that Git Bash starts in the user's home directory, for example (not their Documents folder, but their home directory, i.e. C:\Users\<username>).

fourpastmidnight on 23 Apr 2016

So, here's my list of what I'd like to accomplish, in priority order:

[x] Clean up the ICE17 warnings due to "missing" banner bitmaps
[x] Update the UI to include the option to use the Git Credential Manager for Windows. This shouldn't take long to put the UI in place--just another "Remember Property" and a checkbox.
[x] Add another dialog to give the user the option to install Desktop icons (per-machine) and/or Explorer Shell integration (e.g. Context menu entries for Git Bash Here).
[x] Clean up the localization strings and make the custom Git dialogs use the standard WiX localization strings for buttons.
[x] Create a localization file containing localized text for the Git custom dialogs. (Only en-us, because that's the only language I speak fluently. I'll just butcher the German and Italian that I do know ;) ) But this way, if anyone wants to add support for another language, they can.
[ ] Wire up the custom Git installer properties to actual behavior (e.g. when choosing the command line endings, cli environment, terminal, etc., do the right thing).
- [x] Set Command Line Interface Environment (e.g. Bash vs. Cmd Prompt vs. Both)
- [x] Set Line Ending Options (e.g. Convert on Check-out, Convert on Check-in, None)
- [x] MinTTY or Windows Console?
- [x] Enable Filesystem Caching
- [x] Enable Git Credential Manager for Windows
- [x] Associate .git* files (excluding .gitconfig) with the system default text editor
- [x] [Associate *.sh files with git-bash.exe](https://github.com/fourpastmidnight/build-extra/projects/1#card-327341)
- [x] [Create "Git Bash Here" and "Git GUI Here" Windows Explorer Context Menu Entries](https://github.com/fourpastmidnight/build-extra/projects/1#card-327346)
- [ ] [Create Desktop shortcuts for Git Bash, Git GUI and/or Git CMD](https://github.com/fourpastmidnight/build-extra/projects/1#card-327348)
[x] Modify release.sh to add @BindPath attribute to all <File /> elements generated in GitComponents.sh for the mingw-w64-$ARCH-git package.
[ ] [Author MSI Launch Conditions](https://github.com/fourpastmidnight/build-extra/projects/1#card-327349)
[x] [Make sure the MaintenanceTypeDlg is working properly](https://github.com/fourpastmidnight/build-extra/projects/1#card-327351)
[x] Look into using a Feature Tree selection dialog instead of all of these one-off dialogs. This will be a lot easier to maintain in the future.
- [x] @robmen mentioned possibly switching to the WixUIAdvanced set of UI dialogs, which includes a Feature dialog containing a feature selection tree. I had considered this and decided not to, but I'm more than happy to take another look.

> This doesn't seem like a good idea to me at this time (the "Feature Tree" aspect, that is). Git for Windows doesn't have "features" so much as it has "configurable configurations" that can be chosen at the time of installation.  
> Lastly, the WixUIAdvanced dialog set _may_ make more sense, but until we have this installer actually _working_ (i.e. using the chosen configurations to actually configure Git for Windows during installation), I'm happy to let this pass for the time being and revisit this once things settle down a bit.

[ ] [Update release.sh to take a localization flag [OPTIONAL]](https://github.com/fourpastmidnight/build-extra/projects/1#card-327354)
- [ ] Make the flag optional, it's default value being en-us if left unspecified.
- [ ] Based on the flag value passed from the command line, use the appropriate localization file(s).
  - [ ] If the localization file for the Git dialogs doesn't exist, fail with a helpful error message.
- [ ] Pass the appropriate flags to candle.exe and light.exe calls in release.sh
- [ ] Ensure the MSI filename contains the localization information.
  - E.g. instead of Git-2.8.1-64-bit.msi, it should becomeGit-2.8.1-en-us-64-bit.msi`
[ ] [Look into the Files In Use (or Restart Manager) dialogs](https://github.com/fourpastmidnight/build-extra/projects/1#card-327355) -- this is what instigated this whole "issue" that I opened. A file was in use during the install of a new version of Git for Windows and the InnoSetup installer failed--but it had already uninstalled the prior version of Git for Windows! By attempting to use this, we can at least allow the user the opportunity to close running processes and continue installation. The worst case scenario is the installation cannot proceed, but the system state _has not_ been modified and so you aren't left in a broken state.
[ ] [Make sure Administrative installs work properly.](https://github.com/fourpastmidnight/build-extra/projects/1#card-327358)
~~Get help for authoring the custom dialogs to support repair/reinstall/upgrade scenarios.~~ This is no longer needed--the installer will use "stock" dialogs supplied by WiX.
[ ] [Thoroughly test the installer for both Standard UI and Command Line installation scenarios](https://github.com/fourpastmidnight/build-extra/projects/1#card-327360):
- Regular Installation
- Repair
- Removal
- Upgrade

I think this list is a fairly comprehensive list of things that need to be completed before we can release this thing into the wild.

My first order of business will be rebasing my branch on top of the latest commits on master and updating pull request 113. From there, I'll start working down this list. If anyone wants to jump in somewhere, please just let me know what you're picking up.

fourpastmidnight on 23 Apr 2016

Yes, @fourpastmidnight, you're right about the PersonalFolder for _other_ users. I should have stopped coding after 2am. The arguments method should work well.

robmen on 23 Apr 2016

@robmen No worries. Looking over some of the other changes in PR112, I've already learned a lot about MSI--even things I read over at the FireGiant Wix documentation that I glossed over because I didn't know it applied. For instance, on the post-install.bat and setting @Guid="": I get it! I saw the description in the documentation, but didn't understand until associating the behavior with what happens with this file during installation of Git for Windows.

I have one more question regarding the way you authored the shortcuts: I see that you authored them not as child elements of their target <File />, but rather as siblings within the parent <Component /> element. I'm wondering about the behavior of the installer during repair scenarios. My understanding of components is that they are installed and removed _atomically_. And the determination for whether or not a component needs repairing or installing depends upon whether or not Windows installer finds the installed KeyPath for the component (whether that be a file, directory, or registry entry). So what happens, say, if some unscrupulous user with the right permissions deletes one of the Start Menu shortcuts (for example's sake, let's say Git Bash shortuct) the way you've authored the MSI?

If my understanding is correct and complete, because the KeyPath of the component still exists on disk (git-bash.exe), then a repair of the installation of Git for Windows _would not_ result in the Start Menu shortcut being restored. However, (and this is where I'm unsure if my understanding is correct or complete), if the Shortcut is nested within the <File /> element (for git-bash.exe for example), then a repair install _would_ restore the shortcut, ostensibly because even though the file exists on disk, the shortcut nested witin the <File /> element does not; and since the entire <File /> element is the KeyPath for the component, it must be damaged, and therefore, need reinstallation. Am I correct?

Actually, I think I'll just test it out--seems like a fun learning opportunity. I'll report back with my findings.

fourpastmidnight on 23 Apr 2016

@robmen: Ah!! It did put it back upon repair. I guess my current understanding was incomplete--but now it's more complete than it was. Cool!

And with that, the first item on my list above is checked off--my installer is now using the original make-file-list.sh script.

fourpastmidnight on 23 Apr 2016

@dscho I've only ever used git rebase --interactive once before today. And at that time, I was blindly following what a friend told me to do--I had no idea what I was doing or why. But, after reading that write-up, looking over my commit history and seeing what I wanted to do: WOW, what a tool! I've been wanting to know how to "fix" my commit history for a _long_ time.

Excellent work, sir! This is going into my arsenal of tools; I can't believe I didn't know about this until now.

Anyway, I've fixed up my commit history and the pull request has been updated. I'll now continue on my list above.

Again, if anyone wants to take an item, just ping me and let me know which one you're taking so we don't step on toes.

UPDATE: I see I accidentally reverted a change you made to install.iss to get rid of the obsolete isreadme flag. I'll make sure to fix this on my branch.

fourpastmidnight on 24 Apr 2016

👍1

when you have a minute, I'd appreciate any comments/thoughts you have on what I've done towards #462 and whether or not you feel that fits well with Git for Windows long-term.

I'm leaning towards let's not do it due to the dependency on the Windows SDK.

@fourpastmidnight I agree. Not only does it add a dependency on the Windows SDK, but also on Visual C++ (as WiX is compiled with that compiler, and GCC's C++ ABI is incompatible with Visual C++'s AFAIR).

here's my list of what I'd like to accomplish, in priority order:

@fourpastmidnight Excellent! Thank you so much for communicating in such outstanding a manner!

I'll just butcher the German and Italian that I do know ;)

Please don't. As I am German, and as you know me a little, that would include me :wink:

Seriously again, we do not bundle Git's messages' localizations in the InnoSetup installer, for size reasons. And I am really worrying about size: compared to InnoSetup's 30MB, the MSI seems to weigh in with 44MB already. Most likely there is no way with MSIs to use the _real nice_ LZMA compression? If so, I would be very concerned about increasing the size even further by bundling localizations...

dscho on 24 Apr 2016

@dscho Unfortunately, I don't think we have a choice in MSI compression scheme. I agree, the LZMA is really nice, resulting in a ~50% smaller payload. I'm disappointed that MS over time hasn't updated the installer to support a compression scheme that results in smaller installers.

BTW: You would build one installer per locale (if you wanted to, yourself, provide localized versions). So you wouldn't be "bundling" all the supported languages into one massive installer. Anyway, it would just be _an option_, and the default would be en-us. And one would be able to pass an optional flag to release.sh to choose/change the localized strings _an_ installer is built with. But, since I really only know English well, the custom Git dialogs will only have English localization to begin with.

fourpastmidnight on 24 Apr 2016

You would build one installer per locale

Yeah, I guess I could do that. It would only make the release engineering last several hours more, and I would feel awful about asking GitHub to host _so many_ megabytes of downloads :smile:

dscho on 24 Apr 2016

@dscho No one says _you have to_ 😉 it's an option if you (or someone else) _wants to_. It's a community-driven project, so if the option's there and there's enough "demand", then at that time it may make sense. For now, assume business as usual. 😄

fourpastmidnight on 24 Apr 2016

The pull request was updated. I fixed the ICE17 warnings due to "missing" banner bitmaps and removed some unnecessary localizations because I switched to use WiX's built-in localizations (e.g. for button caption text).

fourpastmidnight on 24 Apr 2016

Just thinking... what if instead of all these remember Properties, we just use Features?

robmen on 25 Apr 2016

@robmen I tried that out tonight. The UX wasn't great. Don't get me wrong, it _worked_, but it _felt_ wrong. Tell you what, I'm done for the night--but tomorrow, let me commit what I worked on wrt. a feature dialog rather than all these custom dialogs. Maybe you'll have some ideas for tweaking it. Using a feature dialog did get rid of three of the 6 custom dialogs.

Maybe I'll put it on a separate branch?

fourpastmidnight on 25 Apr 2016

Yeah, wasn't thinking we need to show the Feature tree necessarily, just use conditional Features to cut down on the registry keys to remember all the settings since the many of these settings seem to be statements of what to install/not install.

Get your PR in a good place and in. It'll be easier to tweak it once there is stuff to work with directly. :smile_cat:

robmen on 25 Apr 2016

Hmm, well, actually all of these "features" are asking the user how to configure git. Most of this configuration seems like it would be based on modifications to .gitconfig (but I haven't looked to see how this is done with the InnoSetup installer). And, from version to version, the user's choices are unlikely to change; so on upgrade, we'd want to present those dialogs with their previous installation options pre-selected. (Or better yet, don't show the dialogs at all at first--ask the user if they want to change their previous configuration; if not, just upgrade using the same settings--two click upgrade, at least, barring new installation options or _actual_ features.) IOW, these registry keys aren't governing whether or not files get installed. It's all about configuration.

One thing I _did_ look into way back at the beginning, which led to my custom make-file-list.sh script, was to determine what packages are installed and what their dependencies are so that it would be possible to selectively decide which packages to install based on actual feature selection. The problem is, after using GraphVis to draw the dependency graph, there are not many independent packages. And, as more things become bundled with Git for Windows, it becomes harder to manage the dependency graph for the small amount of independent packages there are. So this type of install wasn't worth the effort in maintaining the dependency graph. Another reason I _initially_ decided against the WixAdvancedUI dialog set.

In any event, I'll post what I have in terms of a feature dialog. Using the feature tree would be great because it could potentially allow for a two or three click install. But since it's not all that customizable, it didn't have a great UX. But, it doesn't hurt to explore it further for completeness' sake. If I could easily "roll my own", I would--but it's not easy as I'm sure you know. I read Bob Arnson's blog about that last night.

fourpastmidnight on 25 Apr 2016

@robmen My awesome idea:

Given we want as minimal an install as possible (least clicks), then let's present a dialog saying "Here's how Git for Windows will be configured. Do you want to change this configuration?" We could let them select individual configurations to change. Then, only present the necessary dialogs for those configurations. Since these aren't "installed features", per se, we _can_ "roll our own", so to speak, because we don't need the feature tracking normally associated with features. The existing registry entries are good enough.

This would allow two- or three-click installs and upgrades (again, barring new options on upgrade).

fourpastmidnight on 25 Apr 2016

@fourpastmidnight It should be pretty easy to automate ssh-pageant startup as part of the installation (says the guy with no MSI knowledge), at least for the user performing the installation, so that it "just works"in all 3 scenarios... Git Bash, Git CMD, and native Windows command prompt. The installer would need to do the following, presumably based upon user selection:

Set the persistent user environment variable _SSH_AUTH_SOCK_, with a reasonable default value for the location of the physical socket file. I've been recommending SSH_AUTH_SOCK=/tmp/.ssh-pageant-%USERNAME%.
Configure the _[GIT_INSTALLATION]/cmd/start-ssh-pageant.cmd_ script to run automatically at logon (and also at the end of the install process).

There's a Wiki document covering ssh-pageant configuration, which might help to fill in the details. I need to tweak the details just a bit, but it should be largely complete at this point.

landstander668 on 25 Apr 2016

@fourpastmidnight yeah, lots we can do. Let's get the basics in then tweak from there.

@landstander668 that does sound pretty straight forward. A shortcut in the StartupFolder might be friendliest although Run key is another option.

Again, I'd recommend we get what @fourpastmidnight has right now in then open new issues to track adding additional functionality.

robmen on 25 Apr 2016

@robmen Agreed. This is a distraction. Let's not change the UI structure as it currently is right now (other than adding the missing functionality, like Explorer Context menu entries and Desktop shortucts). Let's just get the installer functionality completed and on par with the InnoSetup installer. It doesn't have to be perfect right out of the gate--it just needs to work. Once we get it working, we can revisit the UX and flow--hopefully reducing the number of clicks and in the long run.

fourpastmidnight on 25 Apr 2016

@landstander668 Thanks for the info. We'll take it under advisement for when we get to integrating that into the installer. If you could get around to updating the Wiki to tweak "the details" that need to be tweaked, that would be great. That way, when we're ready to integrate the configuration into the installer, we won't have to go fumbling around to figure out how it works (since I know next to nothing about ssh-pageant :wink:). You'll have plenty of time to do that before we're ready to get there. (I figure a 2 - 4 weeks, _at least_.)

fourpastmidnight on 25 Apr 2016

👍1

@robmen Updated the pull request with some of the things you pointed out. Thanks for looking things over. And, it was my fault about that one document and the line endings. I kept running across it tonight and so I ran a git config --global --list | grep -e autocrlf and wouldn't you know? It came back false. Oops. How did I do that? Anyway, I'm going to have to fix that and make sure the history of this PR looks OK. Sorry about that.

fourpastmidnight on 26 Apr 2016

Updated the pull request with some more commits. It's getting messy, but I've completed about 34% of the items on the list above. Next up: trying to make the user's chosen configuration settings actually _do_ something during install.

fourpastmidnight on 26 Apr 2016

@fourpastmidnight would it be possible to take a moment and try to find a check-in point? You have a lot of good stuff that if committed others could start helping again.

robmen on 26 Apr 2016

@robmen: Sure. I've got the _initial pass_ of the UI more or less complete. I'll clean up the commits and we can see how to proceed from there.

fourpastmidnight on 26 Apr 2016

@dscho, @robmen: Cleaned up my commits and updated the pull request. Let's discuss how to proceed. In the meantime, I'm going to start doing research on how the current InnoSetup installer takes the user's selected options and configures the Git for Windows installation.

I signed off on the pull request--just in case you want to merge it. The installer installs Git for Windows "correctly", and also uninstalls it. But, none of the user choices offered during the setup wizard actually take effect (unless the user remarkably used all the default options--and the PATH default in the UI is outdated: Bash only vs. Both bash and cmd prompt).

fourpastmidnight on 27 Apr 2016

Set the persistent user environment variable SSH_AUTH_SOCK

@landstander668 I think that will break setups where users have multiple Git for Windowses installed (such as is the case with having both Git for Windows and GitHub for Windows).

dscho on 27 Apr 2016

I just saw that I need to rebase with master and resolve some conflicts in my PR. Just checking on this this morning--but I won't be able to resolve these until tonight.

@dscho: I made a comment on GitProduct.wxs--I screwed up my line ending settings in my global git config which resulted in a bad diff (every line is changed!). How do I correct this?

Here's what I've done so far:

Set core.autocrlf = true
After doing that, I got a lot of git warnings about line endings--but that was to be expected. Most warnings were in files I _didn't_ modify. So, after updating my pull request, I ran a git reset --hard.
But how do I fix GitProduct.wxs and release.sh so you can see a proper diff for the actual changes that have been made?

Your help is appreciated.

fourpastmidnight on 27 Apr 2016

Set core.autocrlf = true

Probably you want core.autocrlf = input instead. And we should totally set the line endings correctly in .gitattributes. Probably something like *.wxs eol=lf.

dscho on 27 Apr 2016

But how do I fix GitProduct.wxs and release.sh so you can see a proper diff for the actual changes that have been made?

Sorry, forgot to address that. The easiest method to fix this is to identify the offending commit, then call git rebase -i $COMMIT^ (note the ^ to refer to the parent commit), mark the commit as edit instead of pick, and then fix the line endings using dos2unix <file> or unix2dos <file>, then amending the commit.

dscho on 27 Apr 2016

@dscho:

git rebase -i {sha}^ ... edit... [convert file line endings]

-- That's what I thought--just wanted to make sure. Thanks!!

So, do you want me to add a .gitattributes file to the repository? (I'll be sure to update my git global config settings (or at least, local settings for this repo) as you suggested so that hopefully, this doesn't happen again).

fourpastmidnight on 27 Apr 2016

@fourpastmidnight The Wiki entry for _ssh-pageant_ configuration is now fully tweaked, with the exception of updating this bit after the next official version of Git materializes.

This functionality was integrated after the release of Git 2.8.1, and is expected to become available with the following version.

It should be safe to rely upon the document at this point. (-;

landstander668 on 27 Apr 2016

@landstander668 Thanks!!

fourpastmidnight on 27 Apr 2016

I think that will break setups where users have multiple Git for Windowses installed (such as is the case with having both Git for Windows and GitHub for Windows).

@dscho Not necessarily. If using ssh-agent, it doesn't reuse sockets and should just go ahead and create its own (which then gets eval'd into the environment). If the other Git ssh-pageant, and /tmp resolves to the same path (so that the socket file is already present), it will most likely use the existing socket file without error. I've tested using both the 32-bit and 64-bit versions of Git for Windows, for example, and they'll happily share a single 64-bit ssh-pageant process in that case.

When /tmp resolves to separate locations, such as running both Git for Windows and Cygwin, then the worst case seems to be that both spins up its own ssh-pageant process. Each will happily reuse their own version, however, so you end up with a total of 2 processes (each of which simply communicates with Pageant) in that case. So it still works.

That being said, I've never used GitHub for Windows, so I can't say with 100% certainty at this point.

Update: I'll be setting up a new Windows 10 VM in the next week or so, now that I've acquired a notebook with a bit more horsepower. Will try to verify the GitHub for Windows case once that occurs.

landstander668 on 27 Apr 2016

@dscho Is having multiple installations of Git for Windows possible with the InnoSetup installer? Since it's installed _per-machine_, there's only one uninstallation registration for the application--so how would one go about removing "multiple installations"? (_Actually_, now that I'm thinking about it, the InnoSetup installer lets you install per-user, too, doesn't it?)

Now, if you're talking about the Git that comes with the Git for Windows SDK and then the actual distribution of Git for Windows installed on the same machine--then, yes, I suppose technically you have two installations of Git for Windows.

_Assuming_ this is the case, @landstander668 , what would happen if you started a "long-running" ssh-based Git operation in one instance of Git for Windows (say, backing up your machine using git repositories--I know, I know, this is not the best use of git, but I know someone who does this....), and then starts another ssh-based Git operation in their other instance of Git for Windows? Wouldn't the user experience some kind of socket exception along the lines of SocketInUse or IllegalAccess or something similar (because the two installation instances are trying to use the same socket simultaneously)?

Again, I know the example is contrived, but it _could_ happen (using that "machine backup" scenario as a prime example). Or am I missing something?

fourpastmidnight on 27 Apr 2016

@fourpastmidnight The authentication agent, both ssh-agent and ssh-pageant/Pageant, are only used (for a very brief instant) during public key authentication at the beginning of a SSH session. Once authentication is complete, they're 100% out of the picture... you can shutdown/kill them, and it has no impact on any of the established sessions.

So that shouldn't be a problem. :)

landstander668 on 28 Apr 2016

Ah, I see. I lost the fact that we were talking _only_ about the authentication agent and that the actual transport of data is not occurring over that socket. Thanks for clarifying.

fourpastmidnight on 28 Apr 2016

@dscho: Updated my pull request to resolve conflicts with master.

fourpastmidnight on 28 Apr 2016

do you want me to add a .gitattributes file to the repository?

@fourpastmidnight there already is one: https://github.com/git-for-windows/build-extra/blob/master/.gitattributes :smile:

I think that will break setups where users have multiple Git for Windowses installed (such as is the case with having both Git for Windows and GitHub for Windows).

@dscho Not necessarily.

@landstander668 you are talking about multiple installations side by side using their own /tmp/, but the issue is that you suggested to change the user's _global_ environment, which has only one entry to offer for SSH_AUTH_SOCK. One environment would win. The other would lose.

Is having multiple installations of Git for Windows possible with the InnoSetup installer?

@fourpastmidnight no. But Git for Windows also comes as a Portable Git. So: you can have multiple installations of Git for Windows.

In fact, if you install Git for Windows, and then Git for Windows SDK, you already have two installations.

Now, if you're talking about the Git that comes with the Git for Windows SDK and then the actual distribution of Git for Windows installed on the same machine--then, yes, I suppose technically you have two installations of Git for Windows.

Exactly.

dscho on 28 Apr 2016

...and I must have the option turned on to hide .git* files... :|

fourpastmidnight on 28 Apr 2016

...and I must have the option turned on to hide .git* files...

:smile:

At first I thought it might have been me, but we only hide .git/ by default, not _all_ dotfiles: https://github.com/git-for-windows/git/blob/v2.8.1.windows.1/environment.c#L69 and https://github.com/git-for-windows/git/blob/v2.8.1.windows.1/compat/mingw.c#L429-L432

dscho on 28 Apr 2016

I've begun looking into 3 items in my check list above.

fourpastmidnight on 29 Apr 2016

@landstander668 you are talking about multiple installations side by side using their own /tmp/, but the issue is that you suggested to change the user's global environment, which has only one entry to offer for SSH_AUTH_SOCK. One environment would win. The other would lose.

In that case, it might be better to leave ssh-pageant as an item for the user to configure manually (or alternately, make it optional with an appropriate warning in the installer). Unfortunately, I don't see another option to make it work seamlessly with the Git CMD / native command prompt case.

landstander668 on 29 Apr 2016

@dscho So, it was bothering me.... so I looked at the .gitattributes file. With the addition of the WiX MSI, the file was never updated. So *.wxs has no entry in .gitattributes. Likewise, *.sh files have no entry either. So these files default to whatever one's various .gitconfig settings resolve to (which in my case, were incorrect for this repository). So now I don't wonder how this all came to be. :wink:

Currently, it appears that build-extra/msi/release.sh does have LF line endings. All the *.wx{l,s} files have CRLF line endings. The update-wix-toolset.sh file, however, has CRLF line endings.

fourpastmidnight on 30 Apr 2016

@fourpastmidnight darn. My mistake!

I could fix this here, but it would make your life harder. Because merge conflicts.

So would you kindly use rebase -i to fix the line endings? My suggestion would be to:

start the interactive rebase,
insert an exec bash -i at the top
when the rebase launches that interactive Bash:
1. edit the .gitattributes file to define .sh as LF-only files, commit
2. run dos2unix $(git ls-files \*.sh) and commit
3. edit the .gitattributes to change the .wxs files to LF-only, commit
4. run dos2unix $(git ls-files \*.wxs), commit
5. run git rebase --edit-todo and insert exec unix2dos $(git ls-files \*.wxs) && git commit -a -m pre-fixup before, and exec dos2unix $(git ls-files \*.wxs) && git reset HEAD~2 && git commit -a -C HEAD@{1} after every pick line that touches any .wxs file
6. save the git-rebase-todo file, quit the editor and press Ctrl+D to exit the interactive shell opened by git rebase

This might look like major trickery at first, but is a powerful way to use interactive rebase.

An alternative would be to commit the change to the attributes, use rebase -i to move that commit to the beginning of your branch, and then git filter-branch with the tree filter dos2unix $(git ls-files \*.wxs) to fix the _revisions_ (as opposed to the patches). This would "introduce" the patch to fix the line endings as part of the first commit.

dscho on 1 May 2016

Whoa, I see it. That's cool. OK, I'll do that later today.

@dscho: qq - Wouldn't the "alternative" be better to provide a "flatter" history -- e.g. a clean history with none of this pre-fixup stuff that really isn't pertinent to the changes?

I guess I'm trying to understand the pros/cons between the two methods (as a matter of learning)?

I'm happy to carry out either one and I understand both options equally well.

fourpastmidnight on 1 May 2016

@robmen I have a question. Why do we use <MediaTemplate /> instead of just <Media Id="1" /> When using <MediaTemplate ... />, two CAB files are generated by WiX (but, this can be overridden by applying an attribute). Is there a benefit to using <MediaTemplate /> over <Media />? Or was this simply what you chose to use when you initially started? I'm merely curious.

fourpastmidnight on 1 May 2016

On Sat, 30 Apr 2016, Craig E. Shea wrote:

@dscho: I was looking at install.iss and the method where the
installer attempts to create hard-links for several of Git's
"built-ins". I was questioning the need for this. So I'm looking around
and I decided to see what's changed with git (noticed there were 320
commits on master when just yesterday there were only a few). And then I
happened to notice this
commit
made by you that was merged just today and which is specifically about
this very issue.

It was merged just today, but also many times before, as I recreate the
entire branch structure when performing my regular "merging
rebase".

I would still like to retain the hardlinks: not only do they save space,
but also execution time (spawn are really expensive, and the wrapper is
spawning the _real_ git.exe).

dscho on 2 May 2016

On Sat, 30 Apr 2016, Craig E. Shea wrote:

@dscho: I was reading through the code in install.iss and came across the part where the installer hardlinks DLLs in ming(32|64)/bin to ming(32|64)/libexec/git-core. The question I have is, couldn't we just flat out install the files in the ming(32|64)/libexec/git-core directory instead of messing around with hardlinking?

We are talking about a major duplication of files here, using tons of
unnecessary space... So I'd rather keep the hardlinking (which does not
work on FAT file systems, sadly, but at least on NTFS we're good).

dscho on 2 May 2016

MediaTemplate tries to layout cabinets for optimal install time by getting cabs "a good size". I recommend MediaTemplate and then fix the WiX Toolset to do better automatic layout where it falls down.

robmen on 2 May 2016

Ah, ok. Thanks. The documentation wasn't clear to me what differences are between the two. That's good to know.

fourpastmidnight on 3 May 2016

The installer learned how to remember the user's core.autocrlf choice during installation. Also, the Git for Windows system-wide .gitconfig file is laid down in %ProgramData%\Git as config.

fourpastmidnight on 4 May 2016

The installer "remembered" how to set http.sslCAInfo in the system-wide .gitconfig file which wasn't being set by the MSI previously.

fourpastmidnight on 5 May 2016

The installer "remembered" how to remove pack.packsizelimit=2g on x64 systems. The installer also learned how to set the user's core.fscache choice during installation and configure Git correctly via the system-wide .gitconfig file in %ProgramData%\Git\config.

fourpastmidnight on 6 May 2016

The installer now knows how to enable Git Credentials Manager for Windows when the user selects to enable it during installation.

fourpastmidnight on 6 May 2016

@fourpastmidnight when are you going to commit what you have working thus far? Or do we all just wait until your completely done with your list before doing any additional work?

robmen on 6 May 2016

@robmen Perhaps I misunderstood. I got my pull request up to date a few days ago. I was hoping that @dscho would merge it. That didn't happen. Since then, there have been changes on master, so my PR is out of date again and can't be merged.

Please let me know what exactly you mean by "commit"--commit to where? Other than the PR being a bit out of synch with master, my branch is "working".

fourpastmidnight on 6 May 2016

@fourpastmidnight, sorry, I should not have used "commit" there. Instead I should have said "get your PR accepted by @dscho". I don't know a really a good term for "merge PR". ;)

My experience is that @dscho is very exacting with the code commits (I hope he isn't offended by me saying that :smile:). So, my recommendation is to focus on the commits you have and start refining them as he reviews them. Adding more commits just grows your backlog. :smile_cat:

Right now, I'm frozen on any work waiting for your very large PR to merge. Then I can help refine after that.

robmen on 6 May 2016

@robmen OK, no worries. That's what I thought you meant! :smile: In any event, I got my PR all cleaned up and ready to go, but @dscho never looked at it. From the looks of things, it appears he was in the midst of getting a release together (v2.8.2 just shipped recently), which is probably why nothing has moved.

Since it had been cleaned up for a week and nothing happened with it _and_ since the PR just got merge conflicts in it again, I decided to commit some other work. I'm not trying to purposefully keep anyone else from working on this, I just don't want this thing lingering on without moving forward--especially when I have the know-how and means to move it forward.

In any event, I've got a good chunk of the installation options "wired" up. (OK, I did all the _easy_ ones :wink:.) I'm working on finishing up setting the PATH environment variable based on the user's chosen installation option and then I'll clean things up, rebase the branch, and try and get @dscho's attention :wink:

For the record, I don't think @dscho would be "offended" by saying he's exacting. Of course he is! This software is used by thousands (millions?) of people around the world! It's a big responsibility to make sure that this software, when released, is in a state such that people can reliably install and use it day in and day out. I'm glad he's as picky as he is, even if it causes me a headache sometimes--it just has to be that way. Thanks @dscho for all you do for Git for Windows!

fourpastmidnight on 6 May 2016

I haven't pushed it yet, but the user's installation choice of command line interface PATH environment setting is now honored by the installer on install and upgrade and is removed on uninstallation.

The reason I haven't pushed is because I'm at a good stopping point to clean up my branch and get it up to date with master again so that hopefully @dscho will take a look at the PR and merge it so tha @robmen can join in, too.

So I'll be spending the better part of the day (as I can get an opportunity to work on it) to clean up the branch towards this end. Also, while updating the branch, I'll be following @dscho's instructions to normalize all the files and add the appropriate entries to .gitattributes.

fourpastmidnight on 7 May 2016

@dscho I have updated my branch with master so that my pull request no longer has any conflicts. I would appreciate if you could take a few minutes and look it over.

@robmen's looking forward to getting this merged into master so that we can work together to get this completed.

The installer respects the following settings:

User's selected installation path
User's selected PATH environment setting (Bash only, Command Prompt and Bash, Git and unix tools from command prompt)
- This option supports repair, upgrade, and uninstall scenarios.
Install system-wide git configuration to INSTALLDIR\Git\mingw64\etc\gitconfig.
Configures http.sslCAInfo in the system-wide git configuration with the path to ca-bundle.crt.
Removes pack.packSizeLimit on x64 installations if the limit is set to the default of 2g
Allows the user to choose how to handle line endings (core.autocrlf) and configure git accordingly
- Supports upgrade
- Supports uninstall
- Should support repair
Allows the user to choose to enable core.fscache and configure git accordingly
- Supports upgrade
- Supports uninstall
- Should support repair
Allows the user to choose to enable Git Credentials Manager for Windows and configure git accordingly.
- Supports upgrade
- Supports uninstall
- Should support repair
Adds compat-bash.exe and git*.exe files to the MSI BindImage table with appropriately specified paths.

_Should support repair_ means that I haven't explicitly tested this yet, so only install/uninstall and upgrade are confirmed to work as expected.

Here's an updated list of outstanding items, in relative priority order (according to me :wink:):

[ ] Wire up the custom Git installer properties to actual behavior (e.g. when choosing the command line endings, cli environment, terminal, etc., do the right thing).
- [x] Enable the user to choose to between MinTTY or Windows Console
- [x] Associate .git* files (excluding .gitconfig) with the system default text editor
- [x] [Associate *.sh files with git-bash.exe](https://github.com/fourpastmidnight/build-extra/projects/1#card-327341)
- [x] [Create "Git Bash Here" and "Git GUI Here" Windows Explorer Context Menu Entries](https://github.com/fourpastmidnight/build-extra/projects/1#card-327346)
- [ ] [Create Desktop shortcuts for Git Bash, Git GUI and/or Git CMD](https://github.com/fourpastmidnight/build-extra/projects/1#card-327348)
[ ] [Author MSI Launch Conditions](https://github.com/fourpastmidnight/build-extra/projects/1#card-327349)
[x] [Make sure the MaintenanceTypeDlg is working properly](https://github.com/fourpastmidnight/build-extra/projects/1#card-327351)
[ ] [Look into the Files In Use (or Restart Manager) dialogs](https://github.com/fourpastmidnight/build-extra/projects/1#card-327355) -- this is what instigated this whole "issue" that I opened. A file was in use during the install of a new version of Git for Windows and the InnoSetup installer failed--but it had already uninstalled the prior version of Git for Windows! By attempting to use this, we can at least allow the user the opportunity to close running processes and continue installation. The worst case scenario is the installation cannot proceed, but the system state _has not_ been modified and so you aren't left in a broken state.
~~Get help for authoring the custom dialogs to support repair/reinstall/upgrade scenarios.~~
[ ] [Thoroughly test the installer for both Standard UI and Command Line installation scenarios](https://github.com/fourpastmidnight/build-extra/projects/1#card-327360):
- Regular Installation
- Repair
- Removal
- Upgrade
[ ] [Make sure Administrative installs work properly.](https://github.com/fourpastmidnight/build-extra/projects/1#card-327358)
[ ] [Update release.sh to take a localization flag [OPTIONAL]](https://github.com/fourpastmidnight/build-extra/projects/1#card-327354)
- [ ] Make the flag optional, it's default value being en-us if left unspecified.
- [ ] Based on the flag value passed from the command line, use the appropriate localization file(s).
  - [ ] If the localization file for the Git dialogs doesn't exist, fail with a helpful error message.
- [ ] Pass the appropriate flags to candle.exe and light.exe calls in release.sh
- [ ] Ensure the MSI filename contains the localization information.
  - E.g. instead of Git-2.8.1-64-bit.msi, it should becomeGit-2.8.1-en-us-64-bit.msi`

As you can see, I'm researching a few items for the "MSI-way" to accomplish those items. I'll continue to do some work locally but won't commit anything to my remote-branch until I hear back from @dscho for any remediation that may need to occur. However, I won't wait for more than a few days. I'm on vacation from (official) work this week, so I will be able to get a bit more done than I would otherwise--which would potentially allow me to complete an initial implementation for a quite a few items on this list.

fourpastmidnight on 7 May 2016

@dscho: How do you build edit-git-bash.dll? I see the C file for it, but I don't see anywhere where you compile it. Is it "pre-compiled" and the resulting DLL is simply included in the InnoSetup installation package? (And of course, in this scenario, the source code is available for others to compile the DLL should they need to for some reason.)

I'm asking, because this is as close as InnoSetup gets to "traditional" MSI Custom Actions. And the functionality this DLL is carrying out can only be accomplished via a Custom Action for the MSI. So I would take this same code, but make it "MSI-friendly" (or wrap it in a MSI friendly way) and call it as a custom action.

UPDATE: I'm unsure what that DLL is even trying to do. So, here's the code in install.iss:

if RdbBashTerminal[GB_ConHost].checked then begin
    OverrideGitBashCommandLine(AppDir+'\git-bash.exe','SHOW_CONSOLE=1 APPEND_QUOTE=1 @@COMSPEC@@ /S /C ""@@EXEPATH@@\usr\bin\bash.exe" --login -i');
end;

But, here's the RC string table in the MINGW package for Git:

1 "SHOW_CONSOLE=1 APPEND_QUOTE=1 @@COMSPEC@@ /S /C """"@@EXEPATH@@\\usr\\bin\\bash.exe"" --login -i"

The string the DLL is changing the resource to seems to be the same exact string the resource already is! So, is this DLL even needed?

fourpastmidnight on 8 May 2016

Instead of checkboxes in this very long issue, I'd personally prefer using separate issues to track the work. Then we'd have focused discussions about each and could associate targeted commits against the appropriate issue.

This one is getting loooooong. :smile_cat:

robmen on 8 May 2016

I have been hesitant to say "Yeah, let's do that!" for two reasons:

Until the PR is merged, I'd like to keep everything in one place
I don't want to have to keep track of 10+ different issues

Having said that, however, I _do agree_ that having different issues would potentially be a better way to split up the work and track them individually. If and when the PR gets merged, I would not oppose this. Perhaps, however, when this is "split" into multiple issues, there could be mentions back to this issue and that once one of the "split" issues is closed with a PR, this main issue would be updated to reflect that?

In this way, this sort of remains the "issue of record" while the other are more like "work items" (to use a TFS-ism) where work on a specific item is tracked.

fourpastmidnight on 8 May 2016

I was hoping that @dscho would merge it. That didn't happen. Since then, there have been changes on master, so my PR is out of date again and can't be merged.

@fourpastmidnight I am terribly sorry! I was heads-down in other projects, and did not realize you were waiting for me. :frowning:

This software is used by thousands (millions?) of people around the world!

Indeed. I just looked at the download numbers of Git for Windows v2.8.1 and it has been downloaded almost 1.5 million times.

@dscho I have updated my branch with master so that my pull request no longer has any conflicts. I would appreciate if you could take a few minutes and look it over.

Okay, I started to review it, but have to tend to other things for a few hours. Will come back to it this afternoon.

How do you build edit-git-bash.dll?

It's built via make in the installer/ directory: https://github.com/git-for-windows/build-extra/blob/master/installer/Makefile

I'm unsure what that DLL is even trying to do.

It is used to configure git-bash.exe to use ConHost instead of MinTTY, by editing the resources.

dscho on 9 May 2016

@dscho No worries! As I commented on the PR itself, throughout the day I've been cleaning up and making the changes you requested. I have family from out of town visiting, so I didn't get as much done today as I would've liked. As soon as I get these items worked on, I'll get it all pushed up and give you a holler.

fourpastmidnight on 10 May 2016

@fourpastmidnight Oh, but family comes first! No worries, I won't have _all_ that much time to spend on reviewing patches today, anyway...

dscho on 10 May 2016

Hey all: today was a busy day and I didn't get as much done on resolving some of the PR issues as I would have liked. I did finish up the render-release-notes.sh script, but I need to fix up the commit history before I push these changes up. Once I have done that, I'll give another shout out so those changes can be reviewed. And while review occurs on that, I'll continue to resolve the other items that were pointed out in the PR.

It's my goal to have this PR merged by the end of the week and I hope that I'll have enough time to resolve the issues to make that happen.

fourpastmidnight on 11 May 2016

@dscho: Pushed up my initial implementation of the render-release-notes.sh script for review. I haven't fixed the other items you mentioned--I will start on those items next.

fourpastmidnight on 11 May 2016

Just an update. Since I had family visiting from out of town, I didn't get as much done the last few days as I had hoped--but I had a good time :wink:. Anyway, I finished my first pass through all the items and need to make one final pass to clean up some other things I found as I went along. _Hopefully_, I'll be able to complete this later today and have this all ready for another review. Thanks for your patience.

fourpastmidnight on 15 May 2016

No worries. You are making good progress! And it is really important to have a good time :smile:

dscho on 15 May 2016

@dscho: Thanks for all the great feedback. While making the requested changes, I also found opportunity to split up some more commits and rearrange them so that they flow more smoothly; this also allows every commit to build a working MSI, with each commit adding increasing functionality and feature parity with the InnoSetup installer.

The PR is ready for your review.

fourpastmidnight on 16 May 2016

@dscho: Heads up! I found two issues I need to take care of with the PR before it can be merged and made notes on the relevant lines in msi/GitUI_en-us.wxl and msi/release.sh. I'll have to take care of these tomorrow, though. But please do look over the rest of it so I can make any additional changes you might find.

fourpastmidnight on 16 May 2016

I have one more thing I need to take care of before pushing up all the revisions. Hopefully, this will pass muster... :wink: Thanks for all the feedback.

fourpastmidnight on 18 May 2016

@dscho: OK, I got that one little thing done, and the PR has been updated. Hopefully it all looks good. BTW, I've also updated the PR to remove the [DO NOT MERGE] from the title.

fourpastmidnight on 18 May 2016

@dscho: OK, I updated the pull request. The only problem is, the commits look out of order. The commits are in the correct order in my branch up on my GitHub repo, but not in the PR. Let me know if you need me to do anything about that (such as delete/recreate the PR or something)....

fourpastmidnight on 23 May 2016

It appears that perhaps the author and/or committer dates got messed up, which can be fixed. I'm not going to look into this tonight, I'll look into it tomorrow. It should be a relatively straight forward fix if that's all that happened.

I took a quick look: it looks like because I moved some things around, the author dates are a bit out of order--I just don't know why they don't show these in the order of the actual commit chain. Just let me know how you'd like me to proceed.

fourpastmidnight on 23 May 2016

Yeah, GitHub orders the PR's commits by author date. I don't mind, it is okay!

dscho on 23 May 2016

OK, glad to hear it. Thanks again for all the great feedback throughout working on PR113!

@robmen I have two items above in the checkbox list that I started researching. I could create one issue for both of those, or one issue for each to track work on them, specifically. I'm thinking that as people pick up an item to work on, just make an issue for it and mention _this_ issue in the new issue(s) so everything's linked. Do you have any other thoughts, ideas, comments or concerns?

fourpastmidnight on 23 May 2016

@dscho: re: edit-git-bash.dll

I know we talked about this a bit above. I fundamentally understand it's purpose. However, I tried recompiling edit-git-bash.c as an executable using the make file. I thought that by creating an EXE vs. a DLL, I could then use a custom action from the MSI to invoke the EXE to modify git-bash.exe's resources to update the command line, just like the current InnoSetup installer is doing, when someone wishes to use the Windows Command Console as the terminal emulator, instead of mintty.

Here's what I did:

Installed Git for Windows 2.7.2 (x64) (that's the latest version I have on my test VM--but that doesn't matter for this discussion), selecting to use mintty for the terminal emulator. This resulted in a git-bash.exe that's 137KB with the following resources in git-bash.exe:

"RT_MANIFEST" 1 {XML manifest} ICON {The git for windows icons} STRING 1 STRINGTABLE BEGIN 0, "APP_ID=GitForWindows.Bash ALLOC_CONSOLE=1 usr\bin\mintty.exe -o AppID=GitForWindows.Bash -o RelaunchCommand="@@EXEPATH@@\git-bash.exe" -o RelaunchDisplayName="Git Bash" -i /mingw64/share/git/git-for-windows.ico /usr/bin/bash --login -i" 1, "SHOW_CONSOLE=1 APPEND_QUOTE=1 @@COMSPEC@@ /S /C ""@@EXEPATH@@\usr\bin\bash.exe" --login -i" END GROUP_ICON MAINICON VERSION 1 {Version info for the exe} MANIFEST {Another manifest}

Uninstalled Git for Windows 2.7.2 on my test VM.
Reinstalled Git for Windows 2.7.2 on my test VM, this time choosing to use the standard Windows console for the terminal "emulator". This resulted in a git-bash.exe that's 28KB with the following resources (and this is the _entire_ resource section in the EXE (I didn't omit _anything_)):

STRING 1 STRINGTABLE BEGIN 0, "SHOW_CONSOLE=1 APPEND_QUOTE=1 @@COMSPEC@@ /S /C ""@@EXEPATH@@\usr\bin\bash.exe" --login -i" END

This explains why this git-bash.exe is only 28KB (vs. 137KB), all the other resources are missing: icons, manifests, etc.

Compiled edit-git-bash.c as an executable.
Running edit-git-bash.exe against a fresh copy of git-bash.exe from the GitForWindowsSDK, per the way the InnoSetup installer calls the edit_git_bash(...) function, the git-bash.exe is still 137KB in size, but the following resources are now shown in the executable:

"RT_MANIFEST" 1 {XML Manifest...} ICON {Git for Windows icons} STRING 1 STRINGTABLE BEGIN 0, "SHOW_CONSOLE=1 APPEND_QUOTE=1 @@COMSPEC@@ /S /C ""@@EXEPATH@@\usr\bin\bash.exe" --login -i" END 1 STRING TABLE BEGIN 0, "APP_ID=GitForWindows.Bash ALLOC_CONSOLE=1 usr\bin\mintty.exe -o AppID=GitForWindows.Bash -o RelaunchCommand="@@EXEPATH@@\git-bash.exe" -o RelaunchDisplayName="Git Bash" -i /mingw64/share/git/git-for-windows.ico /usr/bin/bash --login -i" 1, "SHOW_CONSOLE=1 APPEND_QUOTE=1 @@COMSPEC@@ /S /C ""@@EXECPATH@@\usr\bin\bash.exe" --login -i" END GROUP_ICON MAINICON VERSION {version info} MANIFEST 1 {xml manifest info}

Notice the duplicated resources in the STRING section (which I wouldn't even have thought to be a valid executable!). Executing this git-bash.exe resulted in the mintty terminal emulator still being used. It looks like I'm not getting the desired result--in fact, it appears that edit-git-bash.dll and edit-git-bash.exe, compiled from the same source code, and running over the same executable, produce two different results.

Am I doing something wrong? I'm going to keep playing around with this, but if you have any insights, that would be great.

BTW, in case you need to know, I'm currently running Windows 10 Pro, x64. I used the GitForWindowsSDK to compile edit-git-bash.c as an EXE via the supplied Makefile.

UPDATE: I solved part of the mystery.

Why are there now two STRINGTABLE string tables with ID 1? Because each one has a different Language. The original STRINGTABLE in git-bash.exe has LCID 1033 (or 0x0409), which is what I expect. The STRINGTABLE introduced by edit-git-bash.exe has LCID 1024 (0x0400). For what it's worth, when the InnoSetup installer "rewrites" the string resources in git-bash.exe using the DLL version of edit-git-bash, the new resource table _also_ has a LCID of 1024 instead of the original LCID 1033. So something's not quite right with the way edit-git-bash.c is working.

UPDATE 2: Got it to work correctly.

Inside the edit-git-bash.c file, the call to MAKELANGID needs to be changed:

- MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFALT),
+ MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US),

Then, when I run edit-git-bash.exe over git-bash.exe, the string resources are replaced with the correct language version. As a side benefit, all the icons and other resources are preserved (which, at least in v2.7.2, these were being wiped out).

fourpastmidnight on 29 May 2016

it appears that edit-git-bash.dll and edit-git-bash.exe, compiled from the same source code, and running over the same executable, produce two different results.

Not quite... I forgot to recompile the .dll... :blush: (the latest change in edit-git-bash.c is in 8ed99c8 (edit-git-bash: only edit the resources, do not replace them, 2015-12-30) while the latest update of the .dll is in 608741c (Recompile edit-git-bash.dll without debug statements, 2015-05-14))

dscho on 30 May 2016

@dscho: Is it possible to use the Git for Windows SDK on a 64-bit machine to "cross-compile" the edit-git-bash.dll for 32-bit? I've passed the -m32 flag to GCC, but I may need some ld flag(s), too. I'll keep searching. I'm not über familiar with the SDK yet, and how it works--but I'm learning more about it by the hour (for example, I needed to build/install the 32-bit toolchain--which is why I think I need to pass some additional flags to ld). Actually, the biggest problem is my lack of familiarity with MSYS2/MinGW--again, which is changing by the hour as I continue to work with the SDK. :smile:

Also, do you generally build the InnoSetup installer on a 32-bit machine (both the 64-bit version and the 32-bit version)? I assume not, it's just that you had already compiled edit-git-bash.dll as a 32-bit DLL.

UPDATE: Never mind. I need to read a little more closely :blush:

fourpastmidnight on 30 May 2016

So this thread's been a bit quiet. I've been a bit busy and haven't had a lot of time to devote to this, but I've been plugging away when I have a few minutes to enable the installer to respect the user's choice of terminal (which part of this was PR118 that got merged and was released as part of 2.8.4). This has turned out to be a bit trickier than I had hoped. I just wanted to check-in. I'm still very interested in seeing this through to completion so we can actually ship a MSI installer at some point in the future.

fourpastmidnight on 13 Jun 2016

@fourpastmidnight thanks for the update!

dscho on 13 Jun 2016

@dscho: FInally, I have some things ready to move on this. One of these is the implementation of the TERMINAL option for the MSI so that users can now select to use ConHost over mintty. During development of this, I came across several small fixes that need to be made--both to files in the MSI and to the InnoSetup installer. These "fixes" are small in that it only touches 1 or 2 lines in a single file.

My question to you is, how would you best like to handle these? I could create a pull request for each one-file change. This would be beneficial in that the name of the branch being merged is indicative of what's being merged back into master. The downside is I'll have about 3 of these.

Or, I could create one commit for each of these changes on the branch I have for the TERMINAL option, make these commits first, and then put the actual TERMINAL implementation commits last and submit one pull request.

I just don't want to have to do double work splitting or combining commits/branches, etc. But I don't want to overburden you with PRs either.

fourpastmidnight on 19 Jun 2016

Things have quieted down for me once again and I'm able to devote some time to this. Sorry about that!

fourpastmidnight on 14 Jul 2016

I'll be creating a pull request at some point later today. I have to do a bit more testing and fix up my commits. The PR will fix the current implementation of the various properties that are used to determine which settings to use to configure Git for Windows during installation.

fourpastmidnight on 16 Jul 2016

@fourpastmidnight Thank you!

Please note that I released v2.9.2 this morning.

The most important change is that downgrades are detected and discouraged (by asking in interactive mode, suggesting not to downgrade, and flatly refusing in the non-interactive mode). Do you think we can do this in the MSI, too?

I also gave the question some thought whether the MSI or the InnoSetup installer should be the recommended one. Given that InnoSetup-based installers are still way smaller (thanks to LZMA compression), I am leaning towards InnoSetup. I still would love to have MSIs because they have nicer features for sysadmins, of course. What do you think?

dscho on 16 Jul 2016

@dscho:

Warning: This is long. You've been warned. :smile:

Yes, I saw that 2.9.2 was released. :smile:

So, with respect to downgrades, that's a feature that's pretty much something you get "out of the box" with MSI (not that you can't ever downgrade if you're using MSI--just that, typically, you only allow upgrades to occur). The way the MSI is curently setup, downgrades are not allowed. You have to uninstall the version of Git for Windows currently installed in order to install an "older" version.

So now on to the more important topic: which installer should be primary? I'll provide some comments--and yes, I'm slightly biased--but I hope at least that I can provide some food for thought.

With respect to the size of the MSI installer vs. the InnoSetup installer: Honestly, for me, I don't care about this one. Currently, it appears the MSI installer is a little under twice the size of the InnoSetup installer. But in this day and age with the speed of internet access and the cost of hard disk space (even USB thumb drive space, for that matter), I don't see this as a huge show stopper. You may disagree with me on this--but I think this is much ado about nothing at this point. I will concede, however, that this is a fair point over all. I just don't see it as a compelling one.

An MSI installer is definitely great for sys-admins. However, don't forget the whole reason I created this issue: the InnoSetup installer failed to install a new version of Git on my machine and left my machine in an inconsistent state; it had already uninstalled my previous version, but upon encountering an "unrecoverable error", I was left with nothing. MSI totally obviates this scenario. You can actually test this today with the current state of the MSI installer (assuming you can make it fail to install.....maybe by placing a lock on some critical file). I know, because I actually used this "feature" during development of the MSI. :wink:

I'm uncomfortable with having two methods of installation of Git for Windows without having something in place to protect users who, at one point use InnoSetup, and then later use MSI, or vice versa. So, on the one hand, I _may_ be able to engineer the MSI to upgrade from an InnoSetup-based installation. (I've been thinking about this off and on as I've developed the MSI installer.) But then, InnoSetup would need to be modified likewise, to detect an MSI installation and upgrade from that. On the other hand, perhaps it _may_ just be best to detect an InnoSetup installation in the MSI installer (and vice versa) and refuse to continue the installation, guiding the user to use the other installer (or uninstall their current version of Git for Windows before proceeding with the current installer technology). And now that I've written all that, assuming Git for Windows continues to distribute both an InnoSetup and an MSI installer, I think it's probably safest for each installer to detect if Git for Windows has previously been installed by the other and simply refuse to install--it's easier, safer, and less likely to hose someone's machine.

Lastly, where Git for Windows' InnoSetup installer stores it's CurrentVersion information will need to change. I know that you worked hard to get the Visual Studio team to detect the Git for Windows version in the current registry location--but if/when we introduce the MSI installer, Visual Studio will still need to be able to detect the version of Git for Windows that's installed--no matter the installer technology used to install it. The reason the current location used by InnoSetup can't be used is because in MSI, you don't have control over the name of the Uninstall key, unlike in InnoSetup. (And actually, it's not recommended that this location be used for any purposes beyond uninstallation. This location is meant to be opaque (i.e. a black box) to users of the system--it's only used by installers for retrieving uninstallation information.) Currently, the MSI installer stores the CurrentVersion of Git for Windows in HKLM\SOFTWARE\GitForWindows\CurrentVersion. In addition, all other installation configuration information is stored in the HKLM\SOFTWARE\GitForWindows key in the Windows registry. (I'm thinking, there could be some advantages here--but my thoughts are incomplete at this time; when I have given this more thought and have something more concrete to share, I'll ping you.)

These are my immediate thoughts. I look forward to continuing this conversation funther in case I've misunderstood anything or I have an incomplete picture of any of the issues at hand, or just to answer any additional questions you might come up with. :smile: This is a conversation that would need to have occured sooner or later anyway once the MSI is complete and ready to go and prior to actually releasing it "into the wild".

fourpastmidnight on 17 Jul 2016

BTW, I didn't get to "properly" test my latest changes. I fixed up my commit history, but I want to run the installer through a few scenarios before submitting the PR. And that will take some time.

fourpastmidnight on 17 Jul 2016

FWIW, this:

However, don't forget the whole reason I created this issue: the InnoSetup installer failed to install a new version of Git on my machine and left my machine in an inconsistent state;

Was one of the key reasons I created gitsetup in the first place.

robmen on 17 Jul 2016

@dscho At long last--I got that fix in for the MSI properties. I also found a previously unknown bug from PR113 and fixed it. I also took the opportunity to do some other cleanup/fixes related to the properties. See PR125. I'm glad to be able to have submitted this PR, as now I can move forward with the implementation of the MSI to complete other functionality.

fourpastmidnight on 25 Jul 2016

I just noticed that if I uninstall G4W, the %PROGRAMFILES%/Git folder sticks around - is that something that the InnoSetup stuff can't do that this addresses, or should I open a separate issue for this? (If I could get pointed in the right direction, I'd also be happy to PR, but I don't have any experience with building Windows stuff.)

sxlijin on 22 Sep 2016

@sxlijin This issue is tracking the effort to create an MSI installer. Currently, InnoSetup uses a text file that records your installation choices; I don't remember if that file gets left behind on uninstall. Also, there may be some files and/or folders in .\dev that get left behind, IIRC.

What exactly are you seeing being left behind? I'm inclined to tell you, if it bothers you that much, to please open a new issue. Please use the template when opening the new issue to fully describe the problem so that it's clear what the issue is for whomever picks it up--or feel free to poke at it yourself. You would start by looking into the Git for Windows SDK to set up a local Git for Windows development environment on your machine.

fourpastmidnight on 22 Sep 2016

After a long haitus, I'm back. I had a Summer project I needed to take care of that required a lot of any "free" time I had for the entire summer :/. Anyway, I'm going to try and pick up where I left off and get this wrapped up.

One thing I learned right before I had to drop off for a bit was that the way I was going about command line parameters to be passed to MSI for changing the installation options went too far: During re-installs (e.g. to repair an installation), new command line options to change installation options _should not_ be processed. This is because during a reinstallation, the "components" that were installed are still installed and during the reinstallation process no change would be recorded to the installed components even if changes were allowed to be made. What this means is my PR#125 will likely look very different. In fact, I may just abandon that PR and put up a new one. Not to mention the fact that since it's been such a while, my repo is pretty out of date.

fourpastmidnight on 1 Oct 2016

[ ] [Note to self: Ensure that edit-git-bash.exe is not deleted after installation is finished. This is needed during repair installations so that the standard repair can appropriately "patch" git-bash.exe if somehow git-bash.exe were to be deleted.](https://github.com/fourpastmidnight/build-extra/projects/1#card-327405)

The way the current InnoSetup installer works (and currently, the MSI) is edit-git-bash.exe is deleted from the user's system. Maybe this works for InnoSetup, but for MSI, it does not. In MSI, because edit-git-bash.exe is deleted, it's made an "unmanaged" component, which basically means that Windows Installer does not track the installation status of this file. So it gets laid on to the disk, but after that, it forgets about it. If a reinstallation occurs, the standard behavior is to only reinstall a file if the file is older or missing. However, with an "unmanaged" component this check will always succeed because Windows Installer doesn't even care about this component--so edit-git-bash.exe will never be installed; and if the user selected to run Git from the Command Prompt, after repair (where git-bash.exe was renistalled if it was found to be older or missing), it would default to running Git Bash in the MinTTY terminal emulator. A workaround for this would be for users to run a repair installation from the command line: msiexec /famus Git-<Version>-<arch>-bit.msi (the standard flags set with the /f option are omus). This is far from ideal. By simply keeping edit-git-bash.exe around and making it a "managed" component, standard repair scenarios will work "out of the box" for Windows Installer.

The only question now is, where to put edit-git-bash.exe when installing Git for Windows?

UPDATE
So, a way around this, while still deleting edit-git-bash.exe is to not make it an "unmanaged" component. It kind of flies in the face a bit of what you should do in an installer when using MSI, but, even if we delete edit-git-bash.exe, because it's a "managed" component, when the user opts to repair the installation, since edit-git-bash.exe will be missing, it will get reinstalled. Then, if somehow git-bash.exe were corrupted or deleted, it also would be reinstalled, and subsequently, edit-git-bash.exe could "patch" git-bash.exe according to the user's selected installation option.

fourpastmidnight on 1 Oct 2016

So, GitHub introduced this new "project" concept with a Kan-ban board. Sounds like a great way to track work for a large "issue"/feature such as this. I think I'm going to migrate a lot of the "check boxes" in the above posts to this issue over to the project I created on my GH account where I've cloned this repository and track outstanding work items on the board. This is great because as I think of things I need to do, I can quick add a card and not lose track of it. (I know I'm forgetting things by not updating this issue list.). Also, it'll keep the chatter in this issue down. As I have questions or concerns, I'll post here for feedback and help. You can find the project here. I've also updated posts above that had checkboxes in them to cards I've created for the project; so clicking any one of them will take you to the card (and thus, the project).

fourpastmidnight on 2 Oct 2016

The only question now is, where to put edit-git-bash.exe when installing Git for Windows?

In fact, I planned to include the edit-git-bash.exe helper side by side with the git-wrapper.exe redirector in /mingw64/share/git/. Which means that I will have to move the source code from build-extra into MINGW-packages.

I will do that, but first I need to finish the v2.10.1 release.

dscho on 4 Oct 2016

Sounds great!

fourpastmidnight on 4 Oct 2016

Just an update: the new direction I've started going towards based off of a single comment of feedback on PR#125 is going well. I'm currently testing that the installer works as well as what's currently available as of PR#125.

However, I updated my Win10 laptop last night and it's now in a reboot loop....so apparently I'll be troubleshooting that instead of getting actual work done. Joy.

Hopefully I'll have something soon, but testing an installer is extremely slow going.

fourpastmidnight on 13 Oct 2016

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.

fourpastmidnight on 23 Oct 2016

Thanks for keeping the ball going!

dscho on 25 Oct 2016

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?

fourpastmidnight on 12 Nov 2016

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.

mfriedrich74 on 13 Nov 2016

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 on 13 Nov 2016

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.

fourpastmidnight on 14 Nov 2016

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...

dscho on 16 Nov 2016

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 on 18 Nov 2016

@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.

fourpastmidnight on 18 Nov 2016

@fourpastmidnight thank you!

dscho on 18 Nov 2016

@fourpastmidnight thank you for sticking with this!

dscho on 18 Nov 2016

@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.

fourpastmidnight on 7 Dec 2016

Nice!

dscho on 8 Dec 2016

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:

[x] Finish up support for desktop shortcuts
[x] Clean up some of the feature logic
[x] Add support for enabling core.symlinks
[ ] ~~Add the option to configure Git for Windows to use the new experimental diff built-in~~
[X] 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.

fourpastmidnight on 7 Feb 2017

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!!!

dscho on 7 Feb 2017

Upstream Git already accepted the builtin difftool...

That's great news.

fourpastmidnight on 7 Feb 2017

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.

fourpastmidnight on 23 Feb 2017

Good work!

dscho on 24 Feb 2017

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

jcasale on 28 Jun 2017

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.

dscho on 1 Jan 2020

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 notifications@github.com
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
https://github.com/git-for-windows/git/issues/682?email_source=notifications&email_token=ABZH5SHARJFSJ4G4G44AYBTQ3TMPDA5CNFSM4B47O43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5J22I#issuecomment-570072425,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZH5SBVIYWN6NO3RPWCALTQ3TMPDANCNFSM4B47O43A
.

mfriedrich74 on 2 Jan 2020

في خميس، ٢ يناير، ٢٠٢٠ في ٥:٥٢ م، كتب Mike Friedrich <
[email protected]>:

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
<
https://github.com/git-for-windows/git/issues/682?email_source=notifications&email_token=ABZH5SHARJFSJ4G4G44AYBTQ3TMPDA5CNFSM4B47O43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5J22I#issuecomment-570072425
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ABZH5SBVIYWN6NO3RPWCALTQ3TMPDANCNFSM4B47O43A

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/git-for-windows/git/issues/682?email_source=notifications&email_token=ANZCP46NH6T34MGGFNSXLHTQ3X5RBA5CNFSM4B47O43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH6QKHA#issuecomment-570230044,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANZCP472JWTCLYPHEDHPZE3Q3X5RBANCNFSM4B47O43A
.

adel2222 on 2 Jan 2020

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.

dscho on 2 Jan 2020

Dito.

On Thu, Jan 2, 2020, 2:01 PM Johannes Schindelin notifications@github.com
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
https://github.com/git-for-windows/git/issues/682?email_source=notifications&email_token=ABZH5SHRHJZ5IUFOFK47RFLQ3Y2Y5A5CNFSM4B47O43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH7DF7A#issuecomment-570307324,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZH5SHFPQOPQNVHNHG5WWLQ3Y2Y5ANCNFSM4B47O43A
.

mfriedrich74 on 2 Jan 2020

@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. :tada:

robmen on 3 Jan 2020

@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?

dscho on 3 Jan 2020

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. :smile:

robmen on 7 Jan 2020

Do as you wish, @dscho. 😄

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

dscho on 7 Jan 2020

Git: Installer does not roll back properly

All 204 comments

Related issues