t4210: skip command-line encoding tests on mingw

On Windows the application command line is provided as unicode and in
mingw-git we convert that to utf-8. So these tests that require a iso-8859-1
input are being subverted by the encoding transformations we perform and
should be skipped.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
t7102: do not assume the system encoding is utf-8

The commit_msg function has an assumption that the string is being output
as utf-8. On Windows this is not true so always convert from the system
encoding to the desired encoding.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
t6006: be explicit about the encoding of test strings for msysgit

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
t4205: use a file to ensure the encoding is as desired with msysgit

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
t4041: ensure the utf-8 encoded string really gets stored as utf-8.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
t800[12]: work around MSys limitation

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>
t9902: mingw-specific fix for gitfile link files

The path in a .git platform independent link file needs to be absolute
and under mingw we need it to be a windows type path, not a unix style
path so it should start with a drive letter and not a /.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Push the NATIVE_CRLF Makefile variable to C and added a test for native.

Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is
incorrectly set on Mingw git. However, the Makefile variable is not
propagated to the C preprocessor and results in no change. This patch
pushes the definition to the C code and adds a test to validate that
when core.eol as native is crlf, we actually normalize text files to this
line ending convention when core.autocrlf is false.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
MinGW: Update tests to handle a native eol of crlf

Some of the tests were written with the assumption that the native eol would always be lf. After defining NATIVE_CRLF on MinGW, these tests began failing. This change will update the tests to also handle a native eol of crlf.

Signed-off-by: Brice Lambson <bricelam@live.com>
Disable t0110's high-bit test on Windows

The bash Git for Windows uses (i.e. the MSys bash) cannot pass
command-line arguments with high bits set verbatim to non-MSys programs,
but instead converts those characters with high bits set to their hex
representation.

For example, when running

	strings "$(echo -e '\x80')"

(where strings.exe is a MinGW program, not an MSys one) it will complain
about not finding the file called "80".

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fast-export: do not refer to non-existing marks

When calling `git fast-export a..a b` when a and b refer to the same
commit, nothing would be exported, and an incorrect reset line would
be printed for b ('from :0').

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
transport-helper: add trailing --

[PT: ensure we add an additional element to the argv array]
remote-helper: check helper status after import/export

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Always auto-gc after calling a fast-import transport

After importing anything with fast-import, we should always let the
garbage collector do its job, since the objects are written to disk
inefficiently.

This brings down an initial import of http://selenic.com/hg from about
230 megabytes to about 14.

In the future, we may want to make this configurable on a per-remote
basis, or maybe teach fast-import about it in the first place.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Handle http.* config variables pointing to files gracefully on Windows

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>
git stash: make sure that .git/logs/refs/ exists

If the user has not activated reflogs, or if nothing has been recorded
yet (as is the case directly after cloning), said directory may not
exist yet.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fixed wrong path delimiter in exe finding

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>
Fix launching of externals from Unicode paths

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 2ee5a1a14ad17ff35f0ad52390a27fbbc41258f3.

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>
Make non-.exe externals work again

7ebac8cb94f3a06d3fbdde469414a1443ca45510 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>
help: correct behavior for is_executable on Windows

The previous implementation said that the filesystem information on
Windows is not reliable to determine whether a file is executable.
To find gather this information it was peeking into the first two bytes
of a file to see whether it looks executable.
Apart from the fact that on Windows executables are usually defined as
such by their extension it lead to slow opening of help file in some
situations.

When you have virus scanner running calling open on an executable file
is a potentially expensive operation. See the following measurements (in
seconds) for example.

With virus scanner running (coldcache):

$ ./a.exe /libexec/git-core/
before open (git-add.exe): 0.000000
after open (git-add.exe): 0.412873
before open (git-annotate.exe): 0.000175
after open (git-annotate.exe): 0.397925
before open (git-apply.exe): 0.000243
after open (git-apply.exe): 0.399996
before open (git-archive.exe): 0.000147
after open (git-archive.exe): 0.397783
before open (git-bisect--helper.exe): 0.000160
after open (git-bisect--helper.exe): 0.397700
before open (git-blame.exe): 0.000160
after open (git-blame.exe): 0.399136
...

With virus scanner running (hotcache):

$ ./a.exe /libexec/git-core/
before open (git-add.exe): 0.000000
after open (git-add.exe): 0.000325
before open (git-annotate.exe): 0.000229
after open (git-annotate.exe): 0.000177
before open (git-apply.exe): 0.000167
after open (git-apply.exe): 0.000150
before open (git-archive.exe): 0.000154
after open (git-archive.exe): 0.000156
before open (git-bisect--helper.exe): 0.000132
after open (git-bisect--helper.exe): 0.000180
before open (git-blame.exe): 0.000718
after open (git-blame.exe): 0.000724
...

This test did just list the given directory and open() each file in it.

With this patch I get:

$ time git help git
Launching default browser to display HTML ...

real    0m8.723s
user    0m0.000s
sys     0m0.000s

and without

$ time git help git
Launching default browser to display HTML ...

real    1m37.734s
user    0m0.000s
sys     0m0.031s

both tests with cold cache and giving the machine some time to settle
down after restart.

Signed-off-by: Heiko Voigt <heiko.voigt@mahr.de>