This fixes t5516 on Windows. For detailed explanation please refer to code
comments in this commit.
There was a lot of back-and-forth already in vreportf(): d048a96e
(2007-11-09) - 'char msg[256]' is introduced to avoid interleaving 389d1767
(2009-03-25) - Buffer size increased to 1024 to avoid tr
From: Alexandr Miloslavskiy
This also fixes t5516 on Windows VS build.
For detailed explanation please refer to code comments in this commit.
There was a lot of back-and-forth already in vreportf():
d048a96e (2007-11-09) - 'char msg[256]' is introduced to avoid interleaving
389d1767 (2009-03-25)
From: Alexandr Miloslavskiy
This also fixes t5516 on Windows VS build.
For detailed explanation please refer to code comments in this commit.
There was a lot of back-and-forth already in vreportf():
d048a96e (2007-11-09) - 'char msg[256]' is introduced to avoid interleaving
389d1767 (2009-03-25)
This fixes t5516 on Windows. For detailed explanation please refer to code
comments in this commit.
There was a lot of back-and-forth already in vreportf(): d048a96e
(2007-11-09) - 'char msg[256]' is introduced to avoid interleaving 389d1767
(2009-03-25) - Buffer size increased to 1024 to avoid tr
The test was originally designed for the case where user reported that
setting GIT_SSH to a .bat file with spaces in path fails on Windows:
https://github.com/git-for-windows/git/issues/692
The test has two different problems:
1. It succeeds with AND without fix eb7c7863 that addressed user's p
From: Alexandr Miloslavskiy
The test was originally designed for the case where user reported
that setting GIT_SSH to a .bat file with spaces in path fails on
Windows: https://github.com/git-for-windows/git/issues/692
The test has two different problems:
1. It succeeds with AND without fix eb7c
From: Alexandr Miloslavskiy
After I discovered that UTF-16-LE-BOM test was bugged, I decided that
better tests are required. Possibly the best option here is to compare
git results against hardcoded ground truth.
The new tests also cover more interesting chars where (ANSI != UTF-8).
Signed-off-
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
From: Alexandr Miloslavskiy
According to its name, the test is designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32.
While the test succeeds (extra \000\000 are interpreted as NUL),
I myself had an unrelated problem which caused the test to fail.
When an
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
From: Alexandr Miloslavskiy
After I discovered that UTF-16-LE-BOM test was bugged and still
succeeded, I decided that better tests are required. Possibly the best
option here is to compare git results against hardcoded ground truth.
The new tests also cover more interesting chars where (ANSI !=
From: Alexandr Miloslavskiy
According to its name, the test is designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32 file.
While the test succeeds (probably interprets extra \x00\x00 as embedded
zero), I myself had an unrelated problem which caused the te
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
From: Alexandr Miloslavskiy
According to its name, the test its designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32 file.
While the test succeeds (probably interprets extra \x00\x00 as embedded
zero), I myself had an unrelated problem which caused the t
From: Alexandr Miloslavskiy
After I discovered that UTF-16-LE-BOM test was bugged and still
succeeded, I decided that better tests are required. Possibly the best
option here is to compare git results against hardcoded ground truth.
The new tests also cover more interesting chars where (ANSI !=
From: Alexandr Miloslavskiy
Even though Debug configuration builds, the resulting build is incorrect
in a subtle way: it mixes up Debug and Release binaries, which in turn
causes hard-to-predict bugs.
In my case, when git calls iconv library, iconv sets 'errno' and git
then tests it, but in Debu
Even though Debug configuration builds, the resulting build is incorrect in
a subtle way: it mixes up Debug and Release binaries, which in turn causes
hard-to-predict bugs.
In my case, when git calls iconv library, iconv sets 'errno' and git then
tests it, but in Debug and Release CRT those 'errno
17 matches
Mail list logo
