Under Windows XP x64 Edition, the default Command Prompt is a 64-bit process, whereas MinGW's sh.exe needs to be launched as a 32-bit process. This patch explicitly calls the 32-bit cmd.exe from the SysWOW64 under a 64-bit OS in order to launch sh.exe to fix this. Note that under Windows Vista 64-bit this patch would not be needed as the OS seems to automagically find out that sh.exe needs to be called as a 32-bit process.
The Windows Explorer shell extension was still called "Git Shell Here", although all other places refer to it as "Git Bash Here". This was fixed.
Previously, the changes made by the installer to the system always only affected the user running the installer, even if that user was the admin. If an admin is now running the installer, all icons and registry changes (this includes the environment variables and shell extensions) are now performed for all users. The only excpetion is the Quick Launch icon, as there is no common users conceopt for that. For non-admins nothing has changed.
Depending on the directory to install to, the user might require admin or poweruser rights to install. But for installing to directories owned by the user, no special rights are necessary. Installing into those directories was not always possible before. This is hopefully fixed by explicitly setting the required privileges to "none" and only writing to user specific locations.
Signed-off-by: Steffen Prohaska <firstname.lastname@example.org>
The font of the license text in the installer was hardly readable because it was so small. It had to be so small to make the line width match the window width. The new license file comes as an RTF document with nicer formatting which is much more readable.
To make the difference between (Win-)Git and msysGit clearer, I use a different logo for the latter, which is constructed by overlaying the MSys "M" with the Git logo. For future proofing, these logos were designed in Inkscape, and saved as SVG files. Reading this SVG with Gimp, rendering it at 32x32 and saving it as an ICO file yields a logo that hopefully is liked by other people, too. Signed-off-by: Johannes Schindelin <email@example.com>
If an update was performed (i.e. running the installer a second time without uninstalling in between) with different options, it was the case that HOME might be set although not required be the updated install. This is solved by deleting HOME if a previous installation already modified it, before setting it possibly again, similar to what is done for PATH. [sp: adjusted ReleaseNotes.txt] Signed-off-by: Sebastian Schuberth <firstname.lastname@example.org> Signed-off-by: Steffen Prohaska <email@example.com>
If ssh-agent is running in the background, uninstall would not be able to remove it, leaving files and directories on disk after uninstall. This is fixed by issuing a warning before uninstall starts if ssh-agent.exe cannot be deleted, asking the user to stop all ssh-agent processes and run uninstall again. [sp: adjusted ReleaseNotes.txt ] Signed-off-by: Sebastian Schuberth <firstname.lastname@example.org> Signed-off-by: Steffen Prohaska <email@example.com>
Collect all Helper functions are in a first code section. [sp: split Sebastian's original commit into two] Signed-off-by: Sebastian Schuberth <firstname.lastname@example.org> Signed-off-by: Steffen Prohaska <email@example.com>
The documentation contain txt files that should contain the correct line endings on Windows. Therefore they must be checked out using newline conversion. This is now checked before copying files. Signed-off-by: Steffen Prohaska <firstname.lastname@example.org>
A release should contain some release notes. So here is a first draft. The ReleaseNotes.txt are placed directly in the installation directory. Note, ReleaseNotes.txt is committed _with_ Windows line endings. The file is likely to be displayed in Notepad. Signed-off-by: Steffen Prohaska <email@example.com>
It is sufficient to set HOME if the user chooses to add \bin to PATH in order to be able to use Unix tools from the Windows Command Prompt. Setting HOME is not needed if only \cmd is added because the wrappers in \cmd set HOME before they execute the wrapped command. Signed-off-by: Steffen Prohaska <firstname.lastname@example.org>
If the user chooses to add \cmd to PATH in order to be able to use Git from the Windows Command Prompt, HOME needs to be also set because /etc/profile does not get executed in that case. This patch does this along with introducing a little more generic methods to alter environment variables. If HOME was set by the installer and it was not modified, the uninstaller will remove it again, just like it reverts changes to PATH.
The changes to PATH were done too late in both the installer and uninstaller, so the broadcast triggered by ChangesEnvironment=yes came before the actual change. This has been fixed by changing the environment in earlier installer / uninstaller steps. As a side effect, the user has to choose how to modify PATH now before the files get installed.
The progress bar for creating the built-ins was not really useful as the task was finished so quickly that the user could not even read what was going on, which might rather confuse than please users.
The last two characters of the text describing the last option was truncated. This is fixed now. Signed-off-by: Steffen Prohaska <email@example.com>
The uninstaller did not remove the directory Git was installed to from PATH. It now does, as well as any directories below the installation directory in PATH. For convenience, this is also done if the directories in PATH were not added by the installer in the first place, as they will become invalid after uninstallation anyways.
The functionality to modify PATH was rewritten to better suit our needs (e.g. to be able to first remove all occurrences of the installation directory from PATH prior to installation). The code was simplified and merged into install.iss. The drawback is that we lose Win9x support for now which requires PATH to be set in autoexec.bat. As briefly mentioned above, all paths that start with the installation path are now removed from PATH before setting the new PATH as specified by the user during setup. This avoids wrong PATH settings if a user upgrades or reinstalls with different PATH settings that for the previous installation. Moreover, the options if and how to modify PATH were now moved to a separate wizard page during setup, along with more explaining comments.
At least on non-NTFS systems where built-ins are created by copying files, this step might take a while for the growing number of built-ins. Therefore, a new setup wizard page with a progress bar was introduced that informs the user about the progress of copying files / creating hard links.
Signed-off-by: Johannes Schindelin <firstname.lastname@example.org>
While at it, move the resources into /share/resources. Signed-off-by: Johannes Schindelin <email@example.com>