MSys works very hard to convert Unix-style paths into DOS-style ones.
*Very* hard.
So hard, indeed, that
git blame -L/hello/,/green/
is translated into something like
git blame -LC:/msysgit/hello/,C:/msysgit/green/
As seen in msys_p2w in src\msys\msys\rt\src\winsup\cygwin\path.cc, line
3204ff:
case '-':
//
// here we check for POSIX paths as attributes to a POSIX switch.
//
...
seemingly absolute POSIX paths in single-letter options get expanded by
msys.dll unless they contain '=' or ';'.
So a quick and very dirty fix is to use '-L/;*evil/'. (Using an equal sign
works only when it is before a comma, so in the above example, /=*green/
would still be converted to a DOS-style path.)
Commit-message-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The test separator char is a colon which means any absolute paths on windows
confuse the tests that use global_excludes.
Suggested-by: Karsten Blees <karsten.blees@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Apparently the signal handling is not quite correct in the fsckobject
handling (most likely we rely on a side effect that lets us still output
some message after receiving a signal 13 but in the BuildHive setup this
fails intermittently).
As a consequence, the push in t5504 does fail as expected, but fails to
output anything (unexpected). Since this is good enough for now, let's
handle an empty output as success, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This happens only when the corresponding commits are not exported in
the current fast-export run. This can happen either when the relevant
commit is already marked, or when the commit is explicitly marked
as UNINTERESTING with a negative ref by another argument.
This breaks fast-export basec remote helpers.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Between the libgit2 and the Git for Windows project, there has been a
discussion how we could share Git configuration to avoid duplication (or
worse: skew).
Earlier, libgit2 was nice enough to just re-use Git for Windows'
C:\Program Files (x86)\Git\etc\gitconfig
but with the upcoming Git for Windows 2.x, there would be more paths to
search, as we will have 64-bit and 32-bit versions, and the
corresponding config files will be in %PROGRAMFILES%\Git\mingw64\etc and
...\mingw32\etc, respectively.
Therefore we came to a consensus to use %PROGRAMDATA%\Git as the
location for Git-specific files that are of wider interest than just Git
for Windows.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
"diff-highlight" (in contrib/) used to show byte-by-byte
differences, which meant that multi-byte characters can be chopped
in the middle. It learned to pay attention to character boundaries
(assuming the UTF-8 payload).
* jk/colors:
diff-highlight: do not split multibyte characters
Test fixes.
* jk/test-annoyances:
t5551: make EXPENSIVE test cheaper
t5541: move run_with_cmdline_limit to test-lib.sh
t: pass GIT_TRACE through Apache
t: redirect stderr GIT_TRACE to descriptor 4
t: translate SIGINT to an exit
MSys2 emulates pseudo terminals via named pipes, and isatty() returns 0
for such file descriptors. Therefore, some interactive functionality (such
as launching a pager, asking if a failed unlink should be repeated etc.)
doesn't work when run in a terminal emulator that uses MSys ptys (such as
mintty).
However, MSys uses special names for its pty pipes ('msys-*-pty*'), which
allows us to distinguish them from normal piped input / output.
On startup, check if stdin / stdout / stderr are connected to such pipes
using the NtQueryObject API from NTDll.dll. If the names match, adjust the
flags in MSVCRT's ioinfo structure accordingly.
Signed-off-by: Karsten Blees <blees@dcon.de>
This reverts commit 04cde2429a.
The MSYS_TTY_HANDLES trick doesn't work in a second shell window.
Additionally, #undef'ing 'isatty()' at the top of mingw.c breaks yes / no
questions (ask_yes_no_if_possible()) and probably other uses of isatty()
in mingw.c.
Signed-off-by: Karsten Blees <blees@dcon.de>
For performance reasons `stdout` is not unbuffered by default. That leads
to problems if after printing to `stdout` a read on `stdin` is performed.
For that reason interactive commands like `git clean -i` do not function
properly anymore if the `stdout` is not flushed by `fflush(stdout)` before
trying to read from `stdin`.
In the case of `git clean -i` all reads on `stdin` were preceded by a
`fflush(stdout)` call.
Signed-off-by: nalla <nalla@hamal.uberspace.de>
When building the `doc` with `asciidoctor`, `asciidoctor` complains about
a nested code block in a callout list. This is a really dirty solution to
restore the callout list to function properly. There is a minimal visual
sideeffect; the *immitated* codeblock has no overall greyish background.
Instead the individual lines have it.
Note: When building this patch with `asciidoc` the background is totally
gone but the font is still monospaced.
Signed-off-by: nalla <nalla@hamal.uberspace.de>
The `user-manual.txt` ist designed as a `book` but the `Makefile` wants to
build it as an `article`. This seems to be a problem when building the
documentation with `asciidoctor`. Furthermore the parts *Git Glossary*
and *Apendix B* had no subsections which is not allowed when building with
`asciidoctor`. So lets add a *dummy* section.
Signed-off-by: nalla <nalla@hamal.uberspace.de>
In this developers' setup, HAVE_LIBCHARSET_H is apparently defined, but
we *really* want to override the locale_charset() here.
Reminder: at the next merging rebase, fix the ACP typo as requested by
Karsten.
HOME initialization was historically duplicated in many different places,
including /etc/profile, launch scripts such as git-bash.vbs and gitk.cmd,
and (although slightly broken) in the git-wrapper.
Even unrelated projects such as GitExtensions and TortoiseGit need to
implement the same logic to be able to call git directly.
Initialize HOME in git's own startup code so that we can eventually retire
all the duplicate initialization code.
Signed-off-by: Karsten Blees <blees@dcon.de>
Lets keep the environment initialization and conversion section as lean as
possible and move recently added tweaks to setup_windows_environment().
This fixes the following potential problems:
* Prevent duplicate TZ variables if both TZ and MSYS2_TZ are set.
* Some of the higher level x* APIs from wrapper.c require a working
getenv(), using e.g. xstrdup() during initialization is dangerous.
* Slashifying the Windows TMP variable may break native Windows programs,
use POSIX TMPDIR instead.
* Properly slashify TMPDIR even if it is already set, and also if we only
have TEMP, but not TMP.
* Reduce complexity from O(n) to O(log n).
Signed-off-by: Karsten Blees <blees@dcon.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>
Git on native Windows exclusively uses UTF-8 for console output (both with
mintty and native console windows). Gettext uses setlocale() to determine
the output encoding for translated text, however, MSVCRT's setlocale()
doesn't support UTF-8. As a result, translated text is encoded in system
encoding (GetAPC()), and non-ASCII chars are mangled in console output.
Use gettext's bind_textdomain_codeset() to force the encoding to UTF-8 on
native Windows.
Signed-off-by: Karsten Blees <blees@dcon.de>
Add the following clarifier with the next merging rebase:
Note: cURL manages to set the variable CHARSET when nedmalloc is *not*
enabled, without causing an access violation. In that case, it sets it
successfully to the value "cp1252" (hence it is our choice, too, cURL may
need it, Git does not).
This developer should really, really have known better. The fact that we
are changing the environment in ways for which the MSVCRT is not
prepared for is bad enough. But then this developer followed the request
to re-enable nedmalloc -- despite the prediction that it would cause an
access violation, predicting it in the same message as the request to
re-enable nedmalloc, no less!
To paper over the issue until the time when this developer finds the
time to re-design the Unicode environment handling from scratch, let's
hope that cURL is the only library we are using that *may* set an
environment variable using MSVCRT's putenv() after we fscked the
environment up.
Note: this commit can serve as no source of pride to anyone, certainly
not yours truly. It is necessary as a quick and pragmatic stop gap,
though, to prevent worse problems.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
