When shell scripts access a $TMP variable containing backslashes, they
will be mistaken for escape characters. Let's not let that happen by
converting them to forward slashes.
This fixes t7800 with MSys2.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There is a really useful debugging technique developed by Sverre
Rabbelier that inserts "bash &&" somewhere in the test scripts, letting
the developer interact at given points with the current state.
Another debugging technique, used a lot by this here coder, is to run
certain executables via gdb by guarding a "gdb -args" call in
bin-wrappers/git.
Both techniques were disabled by 781f76b1(test-lib: redirect stdin of
tests).
Let's reinstate the ability to run an interactive shell by making the
redirection optional: setting the TEST_NO_REDIRECT environment variable
will skip the redirection.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This test is susceptible to MSys2's posix-to-windows path mangling; Let's
just use POSIX paths throughout and let the tests pass.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With MSys2, there is actually an implementation of mkfifo available. The
only problem is that it is only emulating named pipes through the MSys2
runtime; The Win32 API has no idea about named pipes, hence the Git
executable cannot access those pipes either.
The symptom is that Git fails with a '<name>: No such file or directory'
because MSys2 emulates named pipes through special-crafted '.lnk' files.
The solution is to tell the test suite explicitly that we cannot use
named pipes when we want to test a MinGW Git.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
MSys2 actually allows to create files or directories whose names contain
tabs, newlines or colors, even if plain Win32 API cannot access them.
As we are using an MSys2 bash to run the tests, such files or
directories are created successfully, but Git has no chance to work with
them because it is a regular Windows program, hence limited by the Win32
API.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With MSys2, the "TZ" environment variable gets filtered out when calling
non-MSys2 executables. The reason is that Windows' time zone handling is
substantially different from the POSIX one.
However, we just taught Git for Windows' fork of the MSys2 runtime to
pass on the timezone in a different environment variable, MSYS2_TZ for
the sole purpose of Git being able to reinterpret it correctly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The unsetenv code has no idea to update our environ_size, therefore
causing segmentation faults when environment variables are removed
without compat/mingw.c's knowing (MinGW's optimized lookup would try
to strcmp() against NULL in such a case).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It does not quite work because it produces DOS line endings which the
shell does not like at all.
This lets t3406, t3903, t4254, t7400, t7401, t7406 and t7407 pass.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This just makes things compile, the test suite needs extra tender loving
care in addition to this change. We will address these issues in later
commits.
While at it, also allow building MSys2 Git (i.e. a Git that uses MSys2's
POSIX emulation layer).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git for Windows lags a little bit behind with the 2.x releases because
the Git for Windows developers wanted to let that big jump coincide with
a well-needed overhaul of the context within which Git for Windows is
developed.
To understand why this is such a big issue, it needs to be noted that
many parts of Git are not written in portable C, but instead relies on a
POSIX shell and Perl to be available. Even in the portable C part, there
is the ingrained notion that we can work with UTF-8 encoded strings.
To support the scripts, Git for Windows has to ship a minimal POSIX
emulation layer with Bash and Perl thrown in, and when the Git for
Windows effort started originally, in August 2007, we settled on using
MSys, a stripped down version of Cygwin. Consequently, the original name
of the project was "msysGit" (which, sadly, caused a *lot* of confusion
because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, we used MSys, too: it sports
an additional version of the GNU C Compiler that targets the plain
Win32 API (with a few convenience functions thrown in) instead of the
POSIX emulation layer that would require the MSys runtime to run the
compiled programs. That way, Git for Windows' executable(s) are really
just Win32 programs. To discern executables requiring the POSIX
emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though: some of our
changes to the MSys runtime -- necessary to support Git for Windows
better -- were not accepted upstream, the MSys runtime was not developed
further to support e.g. UTF-8 or 64-bit, and apart from not having a
package management system until much later (when mingw-get was
introduced), many packages provided by the MSys/MinGW project lag behind
the respective source code versions, in particular Bash and OpenSSL. For
a while, the Git for Windows project tried to remedy the situation by
trying to build newer versions of those packages, but the situation
quickly became untenable, especially with problems like the Heartbleed
bug requiring swift action and Git for Windows contributors being scarce
-- despite millions of downloads suggesting that there are many users.
After a brief push in the direction of mingw-get, thanks to the
long-time contributor and co-maintainer Sebastian Schuberth, it became
clear that we need to look for alternatives.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x. MSys2
is a rewrite of the spirit of MSys: it is again a stripped down version
of Cygwin, but it is actively kept up-to-date with Cygwin's source code.
Thereby, it already supports Unicode internally, and it also offers the
64-bit support that we yearned for since the beginning of the Git for
Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from `yum` or `apt-get`, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple `pacman -Syu` will update all installed packages to
the newest versions currently available.
MSys2 is also *very* active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, and a couple of patches await their
submission to the respective upstream projects. Yet without MSys2, the
modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The excellent MSys2 project brings a substantially updated MinGW
environment including newer GCC versions and new headers. To support
compiling Git, let's special-case the new MinGW (tell-tale: the
_MINGW64_VERSION_MAJOR constant is defined).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
MSys2's strace facility is very useful for debugging... With this patch,
the bash will be executed through strace if the environment variable
GIT_STRACE_COMMANDS is set, which comes in real handy when investigating
issues in the test suite.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This way the libraries get properly installed into the "site_perl"
directory and we just have to move them out of the "mingw" directory.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
On Windows, we would like to be able to have a default http.sslCAinfo
that points to an MSys path (i.e. relative to the installation root of
Git). As Git is a MinGW program, it has to handle the conversion
of the MSys path into a MinGW32 path itself.
Since system_path() considers paths starting with '/' as absolute, we
have to convince it to make a Windows path by stripping the leading
slash.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When calculating hashes from pointers, it actually makes sense to cut
off the most significant bits. In that case, said warning does not make
a whole lot of sense.
So let's just work around it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
HANDLE is defined internally as a void *, but in many cases it is
actually guaranteed to be a 32-bit integer. In these cases, GCC should
not warn about a cast of a pointer to an integer of a different type
because we know exactly what we are doing.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the result of a (a, 0) expression is not used, GCC now finds it
necessary to complain with a warning:
right-hand operand of comma expression has no effect
Let's just pretend to use the 0 value and have a peaceful and quiet life
again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With __USE_MINGW_ANSI_STDIO defined to 0, the printf/scanf formats
magically stop throwing warnings!
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Rename to
config.mak.uname: support MSys2
to make it easier to find the latest merging rebase via
git rev-parse ':/Start'
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ignoring a merge can be read as ignoring the changes a merge commit
introduces altogether, as if the entire side branch the merge commit
merged was removed from the history. But that is not what happens
if "-p" is not specified. What happens is that the individual
commits a merge commit introduces are replayed in order, and only
any possible merge conflict resolutions or manual amendments to the
merge commit are ignored.
Get this straight in the docs.
Also, do not say that merge commits are *tried* to be recreated. As that is
true almost everywhere it is better left unsaid.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When *Git for Windows* is installed into a directory that has spaces in
it, e.g. `C:\Program Files\Git`, the `git-wrapper` appends this directory
unquoted when fixing up the command line. To resolve this, just quote the
provided `execpath`.
Signed-off-by: nalla <nalla@hamal.uberspace.de>
This undoes the contentious Git wrapper changes I made earlier, and
retains just the bare minimum to equip the Portable Application with a
Git Bash and a Git CMD.
The resource editing has been taken out, i.e. there is no longer a way
to reconfigure on the command-line which terminal emulator is used by
the Git Bash.
While at it, also fix the problems with the Git wrapper when serving as
replacement for the hardlinked builtins which were pointed out by Philip
Oakley in Git for Windows issue 52.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of having the Git wrapper in the /cmd/ directory is to allow
adding only a *tiny* set of executables to the search path, to allow
minimal interference with other software applications. It is quite
likely, for example, that other software applications require their own
version of zlib1.dll and would not be overly happy to find the version
Git for Windows ships.
The /cmd/ directory also gives us the opportunity to let the Git wrapper
handle the `gitk` script. It is a Tcl/Tk script that is not recognized
by Windows, therefore calling `gitk` in `cmd.exe` would not work, even
if we add all of Git for Windows' bin/ directories.
So let's use the /cmd/ directory instead of adding /mingw??/bin/ and
/usr/bin/ to the PATH when launching Git CMD.
The way we implemented Git CMD is to embed the appropriate command line
as string resource into a copy of the Git wrapper. Therefore we extended
that syntax to allow for configuring a minimal search path.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We recently added the ability to configure copies of the Git wrapper to
launch custom command-lines, configured via plain old Windows resources.
The main user is Git for Windows' `git-bash.exe`, of course. When the
user double-clicks the `git bash` icon, it makes sense to start the Bash
in the user's home directory.
Third-party software, such as TortoiseGit or GitHub for Windows, may
want to start the Git Bash in another directory, though.
Now, when third-party software wants to call Git, they already have to
construct a command-line, and can easily pass a command-line option
`--no-cd` (which this commit introduces), and since that option is not
available when the user double-clicks an icon on the Desktop or in the
Explorer, let's keep the default to switch to the home directory if the
`--no-cd` flag was not passed along.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When we rewrite the command-line to call the *real* Git, we want to skip
the first command-line parameter. The previous code worked in most
circumstances, but was a bit fragile because it assumed that no fancy
quoting would take place.
In the next commit, we will want to have the option to skip more than
just one command-line parameter, so we have to be much more careful with
the command-line handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the meantime, Git for Windows learned to handle those subcommands
quite well itself; There is no longer a need to special-case them in the
wrapper.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In a push to polish Git for Windows more, we are moving away from
scripts toward proper binaries.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper does one thing, and does it well: setting up the
environment required to run Git and its scripts, and then hand off to
another program.
We already do this for the Git executable itself; in Git for Windows'
context, we have exactly the same need also when calling the Git Bash or
Git CMD. However, both are tied to what particular shell environment you
use, though: MSys or MSys2 (or whatever else cunning developers make
work for them). This means that the Git Bash and Git CMD need to be
compiled in the respective context (e.g. when compiling the
mingw-w64-git package in the MSys2 context).
Happily, Windows offers a way to configure compiled executables:
resources. So let's just look whether the current executable has a
string resource and use it as the command-line to execute after the
environment is set up. To support MSys2's Git Bash better (where
`mintty` should, but might not, be available), we verify whether the
specified executable exists, and keep looking for string resources if it
does not.
For even more flexibility, we expand environment variables specified as
`@@<VARIABLE-NAME>@@`, and for convenience `@@EXEPATH@@` expands into
the directory in which the executable resides.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The intention of this change was to make it easier for the Git for
Windows installer, or for power Git users, to change the command-line
launched when executing Git Bash. The idea was to allow reconfiguring
the Git Bash to run different terminals than MSys2's default, mintty.
However, the comments this commit got let no room for misunderstanding:
at least three developers who gained trust by being active in the Git
for Windows offered their vetoes.
RIP, resource editor.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Instead of making it possible to change the .exe icon of git-bash.exe or
git-cmd.exe, this change was compared to adding the option to format USB
drives.
Let's get rid of this change, therefore, before real people are harmed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Otherwise the output of Git commands cannot be caught by, say, Git GUI
(because it is running detached from any console, which would make
`git.exe` inherit the standard handles implicitly).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
