On Windows >= Vista, not having an application manifest with a
requestedExecutionLevel can cause several kinds of confusing behavior.
The first and more obvious behavior is "Installer Detection", where
Windows sometimes decides (by looking at things like the file name and
even sequences of bytes within the executable) that an executable is an
installer and should run elevated (causing the well-known popup dialog
to appear). In Git's context, subcommands such as "git patch-id" or "git
update-index" fall prey to this behavior.
The second and more confusing behavior is "File Virtualization". It
means that when files are written without having write permission, it
does not fail (as expected), but they are instead redirected to
somewhere else. When the files are read, the original contents are
returned, though, not the ones that were just written somewhere else.
Even more confusing, not all write accesses are redirected; Trying to
write to write-protected .exe files, for example, will fail instead of
redirecting.
In addition to being unwanted behavior, File Virtualization causes
dramatic slowdowns in Git (see for instance
http://code.google.com/p/msysgit/issues/detail?id=320).
There are two ways to prevent those two behaviors: Either you embed an
application manifest within all your executables, or you add an external
manifest (a file with the same name followed by .manifest) to all your
executables. Since Git's builtins are hardlinked (or copied), it is
simpler and more robust to embed a manifest.
A recent enough MSVC compiler should already embed a working internal
manifest, but for MinGW you have to do so by hand.
Very lightly tested on Wine, where like on Windows XP it should not make
any difference.
References:
- New UAC Technologies for Windows Vista
http://msdn.microsoft.com/en-us/library/bb756960.aspx
- Create and Embed an Application Manifest (UAC)
http://msdn.microsoft.com/en-us/library/bb756929.aspx
[js: simplified the embedding dramatically by reusing Git for Windows'
existing Windows resource file, removed the optional (and dubious)
processorArchitecture attribute of the manifest's assemblyIdentity
section.]
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
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>
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>
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
... while waiting for the child process to finish.
The Git wrapper serves, among other things, as git-cmd.exe. In that
role, its primary purpose is to provide an interactive cmd window that
knows where to find Git.
A secondary use of git-cmd.exe is to be able to launch other console
processes that know about Git, e.g. when ConsoleZ wants to call an
interactive Bash (it cannot call git-bash.exe because that would open a
new MinTTY window). To this end, git-cmd.exe supports the --command=...
command-line option. The interactive bash would be called like this:
git-cmd --command=usr\bin\bash.exe -l -i
The command-line arguments after the --command=... options are simply
passed through to the command itself. If no --command=... option is
specified, git-cmd.exe defaults to cmd.exe.
Once git-cmd.exe is launched, it finds the top-level directory of the
Git for Windows installation and then launches the command as a child
process. And this is where things get a little bit tricky: When the user
presses CTRL-C, the cmd window receives WM_KEYDOWN/WM_KEYUP messages
which are then handled by the TranslateMessage function that generates a
CTRL-C event that is sent to the console processes running in the
console window (i.e. both git-cmd.exe and the child process).
If no Console Ctrl Handlers have been registered, the git-cmd.exe
process will simply be terminated, without having waited for the
interactive Bash to quit (it does not quit, of course, because it
handles Ctrl+C by terminating any process launched from within the
Bash). Now both cmd and the Bash compete for user input.
Luckily, the solution is very easy: the Win32 API sports a
SetConsoleCtrlHandler() function to register/unregister Console Ctrl
Handlers. When the NULL pointer is registered as "handler", it "causes
the calling process to ignore CTRL+C input":
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686016.aspx
This is exactly what we need here: while waiting for the child processes
to finish, the git-cmd.exe process itself should not be interruptible by
the user. Immediately after the child process terminates, we unregister
the Console Ctrl Handler.
Note: we need to be careful with changes to the Git wrapper as it serves
many other purposes in addition to git-cmd.exe. For example, it serves
as the cmd\git.exe as well as all of the git-<builtin>.exe stand-ins.
So do we want the same Ctrl+C behavior even in those instances? Yes: If
the user interrupts using Ctrl+C, the child process should terminate
before the Git wrapper.
Also note: We cannot override the Console Ctrl Handler with a function
that simply always returns TRUE: this would prevent the console window
opened via git-cmd.exe from closing, since the Console Ctrl Handler
*also* handles "signals generated by the system when the user closes the
console, logs off, or shuts down the system."
[jes: changed the patch to conform with the surrounding coding style, to
pass NULL as Console Ctrl Handler and unregister it as soon as
appropriate, fixed commit message to be more accurate and informative,
added link to the SetConsoleCtrlHandler() documentation.]
This fixes https://github.com/git-for-windows/git/pull/205
Signed-off-by: Christophe Bucher Developer <christophe.bucher@laposte.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To be precise: when the value of the environment variable is shorter than
its name, we have to move the remaining bytes *after* expanding the
environment variable: we would look for the wrong name otherwise.
When the value is longer than the name, we still need to move the bytes
out of the way first, to avoid overwriting them with the interpolated
text.
This fixes https://github.com/git-for-windows/git/issues/509
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When moving bytes (because the name and the value of the environment
variable to interpolate differ in length), we introduce a variable to
unclutter the code and make it more obvious what is happening.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
After we found the `@@` marker after the key to interpolate, we pretty
much only need the offset *after* the marker. So let's just advance it
instead of adding 2 in many places.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`$HOME/bin/` is quite convenient a place to put user-specific Git
helpers, such as credential or remote helpers.
When run in Git Bash, it is therefore already appended to the PATH;
Let's do the equivalent when run in Git CMD: when `git.exe` is
called, Git is told to look also for scripts and programs in
`$HOME/bin` (this does not modify Git CMD's `PATH`, of course).
This fixes https://github.com/git-for-windows/git/issues/429
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The quoting rules of `cmd.exe` are really, really quirky. In particular,
if there are more than two quotes, the entire set of rules changes. That
is the reason why
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i
works, but
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i "test.sh"
fails with this error message:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
The recommended fix is to pass the /S option to `cmd.exe` and surround
the entire command-line by an extra set of quotes. And here lies the
rub: for that to work, we have to append an extra quote. At the end of
the command-line. *After* the last argument was appended, if any.
This commit supports that use case by introducing the option
"APPEND_QUOTE". The intended usage is to use the following string
resource:
SHOW_CONSOLE=1 APPEND_QUOTE=1
@@COMSPEC@@ /S /C \"\"@@EXEPATH@@\\usr\\bin\\bash.exe\" --login -i
(Note that there are only three quotes on that command-line, the fourth
to be appended due to the `APPEND_QUOTE` setting.)
This is (1/3) to fix https://github.com/git-for-windows/git/issues/396
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper is also used as a redirector for Git for Windows'
bin\bash.exe dropin: for backwards-compatibility, bin\bash.exe exists
and simply sets up the environment variables before executing the
*real* bash.
However, due to our logic to use the directory in which the `.exe`
lives as top-level directory (or one directory below for certain, known
basenames such as `git.exe` and `gitk.exe`), the `PATH` environment
variable was prefixed with the `/bin/bin` and `/bin/mingw/bin`
directories -- which makes no sense.
Instead, let's just auto-detect the top-level directory in the common
case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We should not conflate the 'exepath' with the 'top-level
directory'. The former should be the directory in which the executable
lives while the latter should be the top-level directory ("POSIX root
directory") as far as Git is concerned.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Windows 7 allows users to pin running applications to the task bar. By
setting the application ID, multiple processes can share a single task
bar entry, and this is exactly what we need for `git-bash.exe` which
wants to share the task bar entry with the `mintty.exe` instance it
launches.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of `git-bash.exe` automatically running the Git Bash in the
home directory was to support the start menu item `Git Bash` (which
should not start in C:\Program Files\Git, but in $HOME), and to make
that behavior consistent with double-clicking in `git-bash.exe`
portable Git.
However, it turns out that one of the main use cases of portable Git is
to run the Git Bash in GitHub for Windows, and it should start in the
top-level directory of a given project. Therefore, the concern to keep
double-clicking `git-bash.exe` consistent with the start menu item was
actually unfounded.
As to the start menu item: it can easily be changed to launch
`git-bash.exe` with a command-line option. So let's introduce the
--cd-to-home option for that purpose.
As a bonus, the Git wrapper can now also serve as a drop-in redirector
/bin/bash.exe to provide backwards-compatibility of Git for Windows 2.x
with 1.x: some 3rd-party software expects to find that executable there,
and it also expects it to leave the working directory unchanged.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
By embedding string resources into the Git wrapper executable, it
can be configured to execute custom commands (after setting up the
environment in the way required for Git for Windows to work properly).
This feature is used e.g. for `git-bash.exe` which launches a Bash in
the configured terminal window.
Here, we introduce command-line options to override those string
resources. That way, a user can call `git-bash.exe` (which is a copy of
the Git wrapper with `usr\bin\bash.exe --login -i` embedded as string
resource) with command-line options that will override what command is
run.
ConEmu, for example, might want to call
...\git-bash.exe --needs-console --no-hide --minimal-search-path ^
--command=usr\\bin\\bash.exe --login -i
In particular, the following options are supported now:
--command=<command-line>::
Executes `<command-line>` instead of the embedded string resource
--[no-]minimal-search-path::
Ensures that only `/cmd/` is added to the `PATH` instead of
`/mingw??/bin` and `/usr/bin/`, or not
--[no-]needs-console::
Ensures that there is a Win32 console associated with the spawned
process, or not
--[no-]hide::
Hides the console window, or not
Helped-by: Eli Young <elyscape@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We will enhance the function in the next commit to support @@VAR@@
expansion in the upcoming `--command=<command>` option.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Using different code pages for console input (SetConsoleCP()) and console
output (SetConsoleOutputCP()) doesn't make much sense and may be hazardous
for native Windows programs.
Git uses UTF-8 internally, so it actually needs 'SetConsoleCP(CP_UTF8)'
rather than 'SetConsoleCP(GetACP())'. However, ReadFile() / ReadConsoleA()
are broken with CP_UTF8 (and thus any higher level APIs such as fgetc(),
getchar() etc.). Unicode-aware console input would have to be implemented
via mingw_* wrappers using ReadConsoleW(). As Git typically launches an
editor for anything more complex than ASCII-only, yes/no-style questions,
this is currently not a problem.
Drop 'SetConsoleCP()' from the git-wrapper, so that input and output code
pages stay in sync.
Signed-off-by: Karsten Blees <blees@dcon.de>
When we fall back to starting the Git Bash in the regular Windows
console, we need to show said console's window... So let's introduce yet
another configuration knob for use via string resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With a recent change in Cygwin (which is the basis of the msys2-runtime),
a GUI process desiring to launch an MSys2 executable needs to allocate a
console for the new process (otherwise the process will just hang on
Windows XP). _Git Bash_ is such a GUI process.
While at it, use correct handles when inheriting the stdin/stdout/stderr
handles: `GetStdHandle()` returns NULL for invalid handles, but the
STARTUPINFO must specify `INVALID_HANDLE_VALUE` instead.
Originally, the hope was that only this `NULL` => `INVALID_HANDLE_VALUE`
conversion would be required to fix the Windows XP issue mentioned above
(extensive debugging revealed that starting _Git Bash_ on Windows XP would
yield invalid handles for `stdin` and `stderr`, but *not* for `stdout`).
However, while _Git Bash_ eventually showed a `mintty` when not allocating
a new console, it took around one second to show it, and several seconds
to close it. So let's just include both fixes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With the resource-driven command-line configuration, we introduced the
option to ensure that only the PATH environment variable is edited only
minimally, i.e. only /cmd/ is added (as appropriate for _Git CMD_).
We are about to add another option, so let's refactor the equivalent of
Git's `strip_prefix()` function; It is not *quite* the same because we
have to `memmove()` the remainder to the beginning of the buffer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-wrapper fails to initialize HOME correctly if $HOMEDRIVE$HOMEPATH
points to a disconnected network drive.
Check if the directory exists before using $HOMEDRIVE$HOMEPATH.
Signed-off-by: Karsten Blees <blees@dcon.de>
This change accompanies the `--no-cd` option when configured via
resources. It is required to support `Git Bash Here`: when
right-clicking an icon in the Explorer to start a Bash, the working
directory is actually the directory that is displayed in the Explorer.
That means if the clicked icon actually refers to a directory, the
working directory would be its *parent* directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To avoid that ugly Console window when calling \cmd\git.exe gui...
To avoid confusion with builtins, we need to move the code block
handling gitk (and now git-gui, too) to intercept before git-gui is
mistaken for a builtin.
Unfortunately, git-gui is in libexec/git-core/ while gitk is in bin/,
therefore we need slightly more adjustments than just moving and
augmenting the gitk case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
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>
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>
We are about to use the Git wrapper to call the Git Bash of Git for
Windows. All the wrapper needs to do for that is to set up the
environment variables, use the home directory as working directory and
then hand off to a user-specified command-line.
We prepare the existing code for this change by introducing flags to set
up the environment variables, to launch a non-Git program, and to use
the home directory as working directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The original purpose of the Git wrapper is to run from inside Git for
Windows' /cmd/ directory, to allow setting up some environment variables
before Git is allowed to take over.
Due to differences in the file system layout, MSys2 requires some
changes for that to work.
In addition, we must take care to set the `MSYSTEM` environment variable
to `MINGW32` or `MINGW64`, respectively, to allow MSys2 to be configured
correctly in case Git launches a shell or Perl script.
We also need to change the `TERM` variable to `cygwin` instead of
`msys`, otherwise the pager `less.exe` (spawned e.g. by `git log`) will
simply crash with a message similar to this one:
1 [main] less 9832 cygwin_exception::open_stackdumpfile:
Dumping stack trace to less.exe.stackdump
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git started out as a bunch of separate commands, in the true Unix spirit.
Over time, more and more functionality was shared between the different
Git commands, though, so it made sense to introduce the notion of
"builtins": programs that are actually integrated into the main Git
executable.
These builtins can be called in two ways: either by specifying a
subcommand as the first command-line argument, or -- for backwards
compatibility -- by calling the Git executable hardlinked to a filename
of the form "git-<subcommand>". Example: the "log" command can be called
via "git log <parameters>" or via "git-log <parameters>". The latter
form is actually deprecated and only supported for scripts; calling
"git-log" interactively will not even work by default because the
libexec/git-core/ directory is not in the PATH.
All of this is well and groovy as long as hard links are supported.
Sadly, this is not the case in general on Windows. So it actually hurts
quite a bit when you have to fall back to copying all of git.exe's
currently 7.5MB 109 times, just for backwards compatibility.
The simple solution would be to install really trivial shell script
wrappers in place of the builtins:
for builtin in $BUILTINS
do
rm git-$builtin.exe
printf '#!/bin/sh\nexec git %s "$@"\n' $builtin > git-builtin
chmod a+x git-builtin
done
This method would work -- even on Windows because Git for Windows ships a
full-fledged Bash. However, the Windows Bash comes at a price: it needs to
spin up a full-fledged POSIX emulation layer everytime it starts.
Therefore, the shell script solution would incur a significant performance
penalty.
The best solution the Git for Windows team could come up with is to extend
the Git wrapper -- that is needed to call Git from cmd.exe anyway, and
that weighs in with a scant 19KB -- to also serve as a drop-in replacement
for the builtins so that the following workaround is satisfactory:
for builtin in $BUILTINS
do
cp git-wrapper.exe git-$builtin.exe
done
This commit allows for this, by extending the module file parsing to
turn builtin command names like `git-log.exe ...` into calls to the main
Git executable: `git.exe log ...`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This prepares the wrapper for modifications to serve as a drop-in
replacement for the builtins.
This commit's diff is best viewed with the `-w` flag.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, Git is faced by the challenge that it has to set up certain
environment variables before running Git under special circumstances
such as when Git is called directly from cmd.exe (i.e. outside any
Bash environment).
This source code was taken from msysGit's commit 74a198d:
https://github.com/msysgit/msysgit/blob/74a198d/src/git-wrapper/git-wrapper.c
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Just like we support having alternates pointing to different drives, we
want to support alternates pointing to network shares, i.e. UNC paths.
Technically, what we do in this patch is not to support UNC alternates,
but to support UNC paths when normalizing paths. But the latter implies
the former, and the former really was the motivation for this patch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, we have to emulate the fstat() call to fill out information
that takes extra effort to obtain, such as the file permissions/type.
If all we want is the file size, we can use the much cheaper
GetFileSizeEx() function (available since Windows XP).
Suggested by Philip Kelley.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Often we are mmap()ing read-only. In those cases, it is wasteful to map in
copy-on-write mode. Even worse: it can cause errors where we run out of
space in the page file.
So let's be extra careful to map files in read-only mode whenever
possible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is not really helpful when a `git fetch` fails with the message:
fatal: mmap failed: No error
In the particular instance encountered by a colleague of yours truly,
the Win32 error code was ERROR_COMMITMENT_LIMIT which means that the
page file is not big enough.
Let's make the message
fatal: mmap failed: File too large
instead, which is only marginally better, but which can be associated
with the appropriate work-around: setting `core.packedGitWindowSize` to
a relatively small value.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
7ebac8cb94 made launching of .exe
externals work when installed in Unicode paths. But it broke launching
of non-.exe externals, no matter where they were installed. We now
correctly maintain the UTF-8 and UTF-16 paths in tandem in lookup_prog.
This fixes t5526, among others.
Signed-off-by: Adam Roben <adam@roben.org>
If Git were installed in a path containing non-ASCII characters,
commands such as git-am and git-submodule, which are implemented as
externals, would fail to launch with the following error:
> fatal: 'am' appears to be a git command, but we were not
> able to execute it. Maybe git-am is broken?
This was due to lookup_prog not being Unicode-aware. It was somehow
missed in 2ee5a1a14a.
Note that the only problem in this function was calling
GetFileAttributes instead of GetFileAttributesW. The calls to access()
were fine because access() is a macro which resolves to mingw_access,
which already handles Unicode correctly. But I changed lookup_prog to
use _waccess directly so that we only convert the path to UTF-16 once.
Signed-off-by: Adam Roben <adam@roben.org>
On Windows XP3 in git bash
git clone git@github.com:octocat/Spoon-Knife.git
cd Spoon-Knife
git gui
menu Remote\Fetch from\origin
error: cannot spawn git: No such file or directory
error: could not run rev-list
if u run
git fetch --all
it worked normal in git bash or gitgui tools
In second version CreateProcess get 'C:\Git\libexec\git-core/git.exe' in
first version - C:/Git/libexec/git-core/git.exe and not executes (unix
slashes)
after fixing C:\Git\libexec\git-core\git.exe or
C:/Git/libexec/git-core\git.exe it works normal
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
If multiple threads access a directory that is not yet in the cache, the
directory will be loaded by each thread. Only one of the results is added
to the cache, all others are leaked. This wastes performance and memory.
On cache miss, add a future object to the cache to indicate that the
directory is currently being loaded. Subsequent threads register themselves
with the future object and wait. When the first thread has loaded the
directory, it replaces the future object with the result and notifies
waiting threads.
Signed-off-by: Karsten Blees <blees@dcon.de>
