Prevent installation of x86 and x64 version at the same time

[csware]

Should the installer prevent the installation of the x86 and x64 version at the same time? I'd vote for it.

Otherwise one will have two different git system configurations, template directories and also ca-certificate stores.

[dscho]

@csware have you actually tried that?

[csware]

Yeah, in order to test it and prevent users from headaches.

On x86 windows only the 32-bit git installer works.

On x64 windows both installer do work:

• The 64-bit installer installs to C:\Program Files\Git and uninstall information is stored in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Git_is1
• The 32-bit installer installs to C:\Program Files (x86)\Git and uninstall information is stored in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Git_is1

[dscho]

@csware what I meant is: if you install 32-bit version first and then 64-bit version, most likely you want to replace the former version, just like installing a newer version of Git for Windows should replace the previous version.

I recently used exactly that strategy to upgrade a 32-bit Git for Windows with a 64-bit one in one of my boxes. Therefore I am somewhat reluctant to prohibit exactly that...

[csware]

I just tried both variants, 32bit first and 64-bit first - same result: both are installed at the same time, nothing is replaced

Only the startmenu points to the latest installed version, but if I have the old version on the PATH it's still there.

[vaskrist]

Is there any difference between the 32-bit and 64-bit version - as in the 32-bit being limited in some way compared to the 64-bit?

Most Windows programs that have shell integration only add the context menu items into the respective version (32-bit version only adds the items into the 32-bit version of the menu and the 64-bit version only adds it to the 64-bit version)
This happens for example with Git for Windows 1.9.2-preview20140411, 7-Zip, LockHunter.

As you can see I have LockHunter ("What is locking this folder?") in both menus, but that is because I have both versions (32-bit and 64-bit) installed. And that is why I am thinking about installing 7-zip 32-version too so that don't have to go through the X64 menu item :)

So if you plan on to have just one version installed, please add it to both versions of the menu.

[dscho]

I just tried both variants, 32bit first and 64-bit first - same result: both are installed at the same time, nothing is replaced

Hmm. At the point when the installer start, we may have the information which files to delete (in which case the installer can delete them then). But it could also be hidden in the uninstaller. Would yoy have time to search the registry to find out (the information might be the top-level directory's path only).

[sschuberth]

if you install 32-bit version first and then 64-bit version, most likely you want to replace the former version

I'm not sure we would want that, unless by "replace" you mean to silently uninstall the 32-bit version and install the 64-bit version instead. I was reading "replace" as "install into the same directory", and that's certainly not a good idea as that would 1) install the 64-bit version in C:\Program Files (x86) as opposed to C:\Program Files, and 2) it would be possible to result in a mix of 32-bit and 64-bit executables in the installation directory if the (possibly more up to date) 64-bit installer does not overwrite all 32-bit executables.

I think the least error prone would be a combined 32- and 64-bit installer that always installs the 32-bit Git on 32-bit Windows and the 64-bit Git on 64-bit Windows. However, that would enlarge the installer even more.

[csware]

Why not

• disable the 32-bit installer on x64 and vice versa OR
• make sure that only one version (32bit or 64bit) is installed at the same time by checking before starting the installation.

[sschuberth]

Most Windows programs that have shell integration only add the context menu items into the respective version

True, but since we don't ship git-cheetah anymore we do not have that issue. The "Git Bash" and "Git GUI" context menu entries are not shell extensions, but registry-based, so they work for any OS bitness.

[sschuberth]

@csware What you're suggesting is certainly possible, but IMO it's less clean than a combined installer. I always try to avoid solutions that need to explain something to the user (e.g. in the form of a message dialog) but rather try to make things "just work".

[dscho]

if you install 32-bit version first and then 64-bit version, most likely you want to replace the former version

I'm not sure we would want that, unless by "replace" you mean to silently uninstall the 32-bit version and install the 64-bit version instead.

That is indeed what I meant, I did not mean "replace the files in place".

I think the least error prone would be a combined 32- and 64-bit installer that always installs the 32-bit Git on 32-bit Windows and the 64-bit Git on 64-bit Windows. However, that would enlarge the installer even more.

And by a fair bit. It is already painful to see the installer grow from 24 to 45 megabyte. To see it grow to 90 megabyte -- just for the dubious benefit of maintaining a 32-bit version for the poor souls still stuck with such an OS -- would be very painful. So much that I would even be opposed to it.

Why not

• disable the 32-bit installer on x64 and vice versa OR
• make sure that only one version (32bit or 64bit) is installed at the same time by checking before starting the installation.

The first option is out of the question because we would prevent something with no good basis for preventing it, while some users may very well have the need to stay with 32-bit even on a 64-bit OS.

The second option is actually what we do already, because we replace the start menu items and AFAICT also the uninstaller (there is only one Git entry in Control Panel>Add/Remove Software after installing 32-bit Git and then 64-bit Git).

The only patch required IMO is that files from a previous installation for a different bitness get deleted.

[csware]

The second option is actually what we do already, because we replace the start menu items and AFAICT also the uninstaller (there is only one Git entry in Control Panel>Add/Remove Software after installing 32-bit Git and then 64-bit Git).

Yeah, the start menu items are replaced, but %PATH% is not updated and, here is a difference, there are TWO entries in the control panel.

Silently uninstalling or deleting files should not take place as people might already have updated system config or adjusted their git-core/templates which would be lost. There should at least be a mesagebox asking whether to deinstall the old version and noteing all possible arising problems. - It's not clear why a user installs a different version, maybe the user just did not notice and installing another bitness is not intended.

[dscho]

Silently uninstalling or deleting files should not take place as people might already have updated system config or adjusted their git-core/templates which would be lost. There should at least be a mesagebox asking whether to deinstall the old version and noteing all possible arising problems. - It's not clear why a user installs a different version, maybe the user just did not notice and installing another bitness is not intended.

@csware that sounds awesome until you realize that this would require a substantial amount of code to be added to the installer. How about giving it a try? Any help you could provide would be helpful.