Eventually HowtoRelease.txt should describe all necessary
steps to create a Windows release. For now it only describes
naming conventions of the Windows installer.
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 <prohaska@zib.de>
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 <prohaska@zib.de>
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 <prohaska@zib.de>
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 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.
Copying files in preparation for packing them into an installer
is now available as the separate script 'copy-files.sh <tmpdir>'.
The script is used by old WinGit and WinGit (Inno).
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
This fixes the cmd wrappers for git and gitk to work if
paths contain spaces. And the old state of PATH and HOME
is restored before exit.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
By using a helper script, the installer can now optionally modify the current
user's PATH (which will be undone upon uninstall). Options are:
- Not to modify PATH at all,
- add only Git to PATH (i.e. \cmd),
- add Git and UNIX tools to PATH (i.e. \bin and \mingw\bin).
The default is to only add Git to PATH which seems to be the best compromise
between the convenience to be able to use Git from cmd.exe and avoiding
conflicts between programs with matching names (find, sort).
It seems to be a good idead to be explicit about which "shell" is being used
(esp. as there might be shortcuts later that start Git in a cmd.exe shell
environment). As "Bash" already contains the word "shell", "Git Bash" seems
to be a concise choice.
Whereas on some machines the icon listed in the "Change or Remove Programs"
panel seems to automatically match the one of the setup exectuable, there
are some reports that this is not always the case, so again be explicit about
this option.
Inno's doc is a little unclear about whether the default is lzma/normal or
lzma/max (see "Compression" docs vs. "InternalCompressLevel" docs), so let's
be explicit.
The MINGW wrapper script for git-gui provides a switch
to change the working directory before launching the
original git-gui. Use this command line switch to implement
the Explorer shell extension.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Defaulting HOME to USERPROFILE is the best option we have:
1) Don't hide git's home from the user because git is not well
contained but shares data, like ssh keys, or .bashrc.
2) The most obvious default on Windows is USERPROFILE. wish also
has this default, which makes things easier. git-gui automatically
has the right HOME.
3) If the user has special needs she can override the default
by explicitly setting HOME.
See also:
http://groups.google.com/group/msysgit/browse_frm/thread/12807411fc0f2dcfhttp://groups.google.com/group/msysgit/browse_frm/thread/aa594775f374ff89
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
The entry in the start menu and the shell extension directly
use wish to launch git-gui. Note, this requires git-gui to
locate git in the same directory git-gui is installed in,
even if this directory is not in PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Using "Start in" in the shortcut properties, the shell now opens in
the Git home directory inside $APPDATA.
Signed-off-by: Sebastian Schuberth <sschuberth@visageimaging.com>
If a user wants to add '-alpha' to the version he can do
so by stating it on the command line. No need to maintain
a special status flag in install.iss
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
To build an Inno Setup based installer run
/share/WinGit-InnoSetup/release.sh <version>
Note, you must have Inno Setup installed on your system.
The script builds on top of WinGit/release.sh and only
adds the files required by Inno Setup.
Signed-off-by: Sebastian Schuberth <sschuberth@visageimaging.com>
HOME is expected to be there. Either HOME is automatically
set to USERPROFILE or it was set present in the environment.
There's no need to create the directory. If it is missing
there's something fundamentally wrong. Hence, we report an
error and quit.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
This commit normalizes the HOME to match the expectation of
Unix programs. All backslashes are converted to slashes. At
least ssh is know to fail to locate its configuration files
if HOME contains backslashes.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Note, fetching HTML pages will not work unless master
of msysgit contains the submodule at doc/git/html.
Therefore, we need to first advance master before we
can thoroughly test this commit. I only tested it with
a temporarily hacked setup-msysgit.sh.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
It is assumed that a matching version of the html documentation
is available as the HEAD of /doc/git/html/.git. If not an error
will be reported.
This patch doesn't include a mechanism to fetch the html pages
to /doc/git/html. The html pages should be at the right place,
which can be handled as a submodule of msysgit.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
We do not want to generate the html documentation in msysgit
but instead take the autogenerated documentation from Junio's
repo. This avoids having to integrate the complete toolchain
with msysgit.
So register a submodule at path doc/git/html, which points to
the html pages for 1.5.3 (which is our current git version in
msysgit).
To actually checkout the html pages you need to run
git-submodule init
git-submodule update doc/git/html
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
By saying "/share/GitMe/release.sh 0.5=devel tmp devel" you will get an
installer that checks out the "tmp" branch of msysgit.git, and the
"devel" branch of 4msysgit.git.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It had a bogus URL, so it could not work, ever. The fact that this
has not been found earlier speaks volumes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We do not want to generate the html documentation in msysgit
but instead take the autogenerated documentation from Junio's
repo. This avoids having to integrate the complete toolchain
with msysgit.
So register a submodule at path doc/git/html, which points to
the html pages for 1.5.3 (which is our current git version in
msysgit).
To actually checkout the html pages you need to run
git-submodule init
git-submodule update doc/git/html
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
If /cmd is already in the PATH, no need to show the message.
While at it, check for a message-of-the-day, and display it if there is one.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Steffen Prohaska
Sebastian Schuberth
Johannes Schindelin
Dmitry Kakurin