Installer does not roll back properly

[fourpastmidnight]

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

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

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

[dscho]

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

We do not have an MSI.

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

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

[fourpastmidnight]

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

[dscho]

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

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

Now, what about your PR?

[fourpastmidnight]

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

[fourpastmidnight]

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

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

[dscho]

Hopefully, I can help improve that.

That would be great!

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

[fourpastmidnight]

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

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

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

[dscho]

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

Very nice!

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

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

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

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

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

[robmen]

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

[fourpastmidnight]

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

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

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

[dscho]

@robmen no worries.

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

[fourpastmidnight]

@robmen same here, no worries.

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

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

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

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

[dscho]

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

Yep.

[fourpastmidnight]

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

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