Integrate into Git for Windows proper

[dscho]

It would appear that an even better way to provide all that gitsetup provides would be to integrate the enhancements into Git for Windows itself.

[robmen]

If you are interested in that, we could definitely look into that.

It is important to note that this setup takes a different approach than the current Git for Windows setup. It has different "opinions" about how to do an install and might not work well for everyone. It doesn't try to please everyone. :)

How would you best like to proceed?

[dscho]

If you are interested in that, we could definitely look into that.

I am.

It is important to note that this setup takes a different approach than the current Git for Windows setup. It has different "opinions" about how to do an install and might not work well for everyone.

This is interesting. What is this "opinion" thing? How does it work? Who does it target?

How would you best like to proceed?

That depends whether I could interest you to integrate your WiX script into Git for Windows' standard release cycle or not... 😜

[hmemcpy]

That depends whether I could interest you to integrate your WiX script into Git for Windows' standard release cycle or not...

That would be a "win-win" 👍

[robmen]

@dscho are you thinking about adding this as a 4th "installer type" to git-for-windows/build-extra? I'm going to assume, "Yes". Ignore the remainder of this response if you have different ideas. 😄

This is interesting. What is this "opinion" thing? How does it work? Who does it target?

gitsetup.exe is designed for Windows developers that use cmd and/or PowerShell and want to treat git as a typical Windows command-line executable. As a result, the many Unix-isms of git are not exposed.

That depends whether I could interest you to integrate your WiX script into Git for Windows' standard release cycle or not...

I took a look at the build process a couple years ago. I do not envy your build dependencies. 😄

I've effectively zero bash experience (and near zero interest in extending it at this time) so I'm of minimal use adding/enhancing the existing scripts in git-for-windows/build-extra.

However, I know the WiX Toolset and the Windows Installer (.msi) very well. I can explain what the current batch files do and manage the .wxs code (and continue to enhance going forward since there are certainly areas to improve).

So I'm game but the question is anyone available to do the build script integration?

[dscho]

are you thinking about adding this as a 4th "installer type" to git-for-windows/build-extra?

Yes 😄

I know the WiX Toolset and the Windows Installer (.msi) very well. I can explain what the current batch files do and manage the .wxs code (and continue to enhance going forward since there are certainly areas to improve).

Perfect. That would help me a lot because I have no time to read up on WiX. Could you walk me through the process?

For comparison, the Git for Windows installer is generated using a script that performs these steps:

• from an up-to-date MSys2 installation, a file list is generated by starting with a list of required packages, getting the full list of transitive dependencies, then excluding a number of unneeded files (this is unfortunately necessary to bring down the installer size from ~55MB to ~30MB which is still more than I would like)
• with this file list (and a couple of added files, such as the release notes), InnoSetup is called to compile the installer from the install.iss definition.

I imagine that a very similar strategy is used to make the .msi here, correct?

the question is anyone available to do the build script integration?

Yes. Me. 😄

[bleissem]

@robmen
I would like to commit myself as a developer for this issue if any help is needed.
I think I can help / support / do the work for @dscho .

[dscho]

@robmen could you give us a walk-through of the basic concepts how gitsetup uses WiX to generate an .msi file? I would be very interested to learn how this is done.

[robmen]

@dscho, yes the strategy will be identical with different input file formats (.wxs files are XML) and tools being called (WiX toolset breaks the build into two steps: compile then link). I expect generating the .wxs files to be the "hardest" part of the shell files.

Do you have a directory structure in mind for organizing the multiple "installers" now? There are enough files unique to each installer build that we won't want to intermingle them. For example, do you want a top level "installer-innosetup" and "installer-wix" folders or do you want sub-folders under "installer"? WIth that guidance in place, I can start bringing over code from this repo into the correct location in git-for-windows/build-extra.

@bleissem very cool. Just need to get a few structural issues out of the way then should be able to start iterating and making progress.

[dscho]

Do you have a directory structure in mind for organizing the multiple "installers" now?

So far, build-extra sports the following subdirectories:

• installer/: the files to build the official .exe installers
• portable/: the files to build the self-extracting .7z.exe portable Gits
• archive/: the files to build the .bz2 archives
• sdk-installer/: the files to build the self-extracting Git for Windows SDK installer

The last one does not concern us, of course, as its release cycle is completely independent from Git for Windows'.

The other three actually share the call to make-file-list.sh (which is located in the top-level directory for that reason) to generate the list of files to include into the installer/portable Gits.

I imagine that we want to add an msi/ subdirectory, containing a release.sh file to generate the .wxs files and call WiX (installing it if required, I guess) to generate the .msi files.

Sounds good?

[robmen]

@dscho (too funny, ships--or issue comments--passing in the night).

For anyone looking at the repo here (namely harvest.cmd), I'd like to move away from using heat.exe and have a script like make-file-list.sh that does the file list generation.

At some point, it will likely be prudent to refactor the shell scripts to extract the commonalities between InnoSetup based build and WiX based build. But I'm probably stating the obvious there. 😸

[dscho]

At some point, it will likely be prudent to refactor the shell scripts to extract the commonalities between InnoSetup based build and WiX based build.

Which files should I look at to figure out what the WiX-based build does before calling the compiler/linker?

[robmen]

I imagine that we want to add an msi/ subdirectory, containing a release.sh file to generate the .wxs files and call WiX (installing it if required, I guess) to generate the .msi files.

Sounds good. I missed the fact that make-file-list.sh was in the root (clicked straight through to the code) but now I can see that it generates a newline delimited list of files. That should be easy enough to work with.

Which files should I look at to figure out what the WiX-based build does before calling the compiler/linker?

Note: this is what my comment above about not using harvest.cmd going forward. Today, the process is three steps.

1. harvest.cmd to generate the GitComponents.wxs.
2. Update the version numbers in the .wxs scripts. I did this because I wasn't confident in the Git for Windows versioning scheme yet and thus hadn't devised a good way of automatically extracting the version from the portable install. This will be much easier now with the version as part of the release.
3. Call make.bat.

So two things:

1. I would look at the GitComponents.wxs file to see what the output should be. The harvest.cmd will not be helpful going forward.
2. I've been seriously considering moving gitsetup to WiX v4 (pre-release). Doing so would make GitComponents.wxs much easier to generate and I would like to make improvements in the core toolset to improve the installation package based on Git for Windows. That was one of the reasons I created the gitsetup project in the first place.

[robmen]

@dscho any thoughts on moving to WiX v4? Are you for/against/neutral using pre-release WiX software?

With that answered, I should be able to create a pull request to create the /msi folder in build-extras with first draft of all the code. I could also add text files with the steps that need to be converted into shell scripts. That should get us into a place to iterate fairly quickly then.

[dscho]

Are you for/against/neutral using pre-release WiX software?

Neutral, but I trust your judgement more than mine.

Thank you for all your explanations, and I look forward to seeing the progress!