When a 1-line file is augmented by a second line, and the user tries to
stage that single line via the "Stage Line" context menu item, we do not
want to see "apply: corrupt patch at line 5".
The reason for this error was that the hunk header looks like this:
@@ -1 +1,2 @@
but the existing code expects the original range always to contain a
comma. This problem is easily fixed by cutting the string "1 +1,2"
(that Git GUI formerly mistook for the starting line) at the space.
This fixes https://github.com/git-for-windows/git/issues/515
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This fixes an issue where the Git wrapper would terminate upon Ctrl+C,
even in the case when its child process would *not* terminate.
Note: while the original intention was to fix running Git Bash in
ConsoleZ, the bug fix applies also to running
C:\Program Files\Git\bin\bash -l -i
in a cmd window.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was a bug in the wrapper where it would interpolate incorrectly if
the name of the environment variable to expand was longer than the value.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch adds the --command=<command> option that allows
starting the Git Bash (or Git CMD) with different terminal emulators
than the one encoded via embedded string resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use msysGit's `git-wrapper` instead of the builtins. This works around
two issues:
- when the file system does not allow hard links, we would waste over
800 megabyte by having 109 copies of a multi-megabyte executable
- even when the file system allows hard links, the Windows Explorer
counts the disk usage as if it did not. Many users complained about
Git for Windows using too much space (when it actually did not). We
can easily avoid those user complaints by merging this branch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch addresses the bug where Git for Windows 2.x' Git GUI
failed to generate a working shortcut via Repository>Create Desktop
Shortcut.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This branch introduces support for reading the "Windows-wide" Git
configuration from `%PROGRAMDATA%\Git\config`. As these settings are
intended to be shared between *all* Git-related software, that config
file takes an even lower precedence than `$(prefix)/etc/gitconfig`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These fixes were necessary for Sverre Rabbelier's remote-hg to work,
but for some magic reason they are not necessary for the current
remote-hg. Makes you wonder how that one gets away with it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When using remotes (with git-flow especially), the remote reference names
are almost always wordwrapped in the "list references" window because it's
somewhat narrow by default. It's possible to resize it with a mouse,
but it's annoying to have to do this every time, especially on Windows 10,
where the window border seems to be only one (1) pixel wide, thus making
the grabbing of the window border tricky.
Signed-off-by: James J. Raden <james.raden@gmail.com>
... 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>
Tcl/Tk 8.6 introduced new events for the cursor left/right keys and
apparently changed the behavior of the previous event.
Let's work around that by using the new events when we are running with
Tcl/Tk 8.6 or later.
This fixes https://github.com/git-for-windows/git/issues/495
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite
small, but there are ways to circumvent that limit in many cases, it is
very important that users be given an indication why their command
failed because of too long paths when it did.
This test case makes sure that a warning is issued that would have
helped the user who reported Git for Windows' issue 521:
https://github.com/git-for-windows/git/issues/521
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>
`$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>
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>
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>
