for UTF-8 emulation,
so it's safe to use xwrite() again 5e5be9e2 (2016-06-28) - recv_sideband()
uses xwrite() again
Signed-off-by: Alexandr Miloslavskiy alexandr.miloslavs...@syntevo.com
[alexandr.miloslavs...@syntevo.com]
Alexandr Miloslavskiy (1):
vreportf: Fix interleaving issues, remove
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 (
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 (
for UTF-8 emulation,
so it's safe to use xwrite() again 5e5be9e2 (2016-06-28) - recv_sideband()
uses xwrite() again
Signed-off-by: Alexandr Miloslavskiy alexandr.miloslavs...@syntevo.com
[alexandr.miloslavs...@syntevo.com]
Alexandr Miloslavskiy (1):
vreportf: Fix interleaving issues, remove
nd 'zlib1.dll'.
Fix both problems by using .bat script instead of 'test-fake-ssh.exe'. NOTE:
With this change, the test now correctly fails without eb7c7863.
Signed-off-by: Alexandr Miloslavskiy alexandr.miloslavs...@syntevo.com
[alexandr.miloslavs...@syntevo.com]
Alexandr M
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
On 28.09.2019 6:47, Junio C Hamano wrote:
s/bugged/buggy/ perhaps? Usually people do not place hidden
listening devices in tests ;-)
Yes, hinting those hidden listening devices was an oversight. Thanks for
your help in putting them back undercover!
I understand that you already changed the
Johannes, would you please review?
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.
On 24.09.2019 8:21, Johannes Sixt wrote:
What are we testing here? Is there some back-and-forth conversion going
on, and are we testing that the conversion happens at all, or that the
correct conversion/encoding is picked, or that the conversion that is
finally chosen is correct? Why does it help
On 24.09.2019 6:06, Torsten Bögershausen wrote:
Would this make more sense:
After I discovered that UTF-16-LE-BOM test was bugged,
I decided that better tests are required
OK
> Looking at the other test cases, should utf-8 be written as UTF-8
> for consistency ?
OK
> General remark:
> Do we
On 24.09.2019 5:46, Torsten Bögershausen wrote:
Out of curiosity:
What made the test fail, and does it pass noe ?
It failed to a bug in Windows Debug build, which caused iconv() to fail
in most cases, see:
https://public-inbox.org/git/pull.348.git.gitgitgad...@gmail.com/
How about the followi
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
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
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
x27; should be used
instead of 'libcurl.lib'. Previously this bug was hidden, because Debug path
was never taken.
Signed-off-by: Alexandr Miloslavskiy alexandr.miloslavs...@syntevo.com
[alexandr.miloslavs...@syntevo.com]
Alexandr Miloslavskiy (1):
contrib/buildsystems: fix Visual S
Johannes, thanks for working on this problem!
In the previous discussion, there was a suggestion to change
'--stdin' to '--paths-file', where '--paths-file -' would mean stdin:
https://public-inbox.org/git/066cfd61-9700-e154-042f-fc9cffbd6...@web.de/
I believe that was a good suggestion for a fe
On 02.08.2019 16:47, Johannes Schindelin wrote:
> and definitely does *not* want to write a file.
In this case it can use `--paths-file -`, which means stdin.
Zilch. So I find the advice you received, let's say, interesting.
I understood that `--paths-file` is suggested to avoid possible
std
On 02.08.2019 16:48, Johannes Schindelin wrote:
How about subscribing to that PR so you get updates without requiring me
to remember to send you a manual email?
This option evaded me :) Subscribed, thanks!
On 02.08.2019 13:33, Johannes Schindelin wrote:
to teach `git reset` an `--stdin` option:
I think it should be changed to follow the approach decided
here [1] - that is, use '--paths-file', and '--paths-file -'
will mean "from stdin"
[1]
https://public-inbox.org/git/a6610e94-6318-b962-5dd0-ca
On 02.08.2019 13:33, Johannes Schindelin wrote:
Please note that I have a patch series (currently on hold because of the
v2.23.0 feature freeze) to teach `git reset` an `--stdin` option:
https://github.com/gitgitgadget/git/pull/133
Perfect! Less work for me :)
Once your patch is accepted, could
@Johannes, thanks a lot for your tips!
On 02.08.2019 13:40, Johannes Schindelin wrote:
From past experience, I find that it is important to also implement the
`-z` option (which traditionally means: accept items via the command
line that are delimited by NULs).
And you might find inspiration i
On 01.08.2019 22:45, Junio C Hamano wrote:
That does not mean that any patch along that line will automatically
be accepted, of course, so the answer to "am I ready to accept"
question is a definite no. No, I am not ready---we will have to
look at the actual patches before deciding.
That's why
On 01.08.2019 22:26, Junio C Hamano wrote:
All true. Perhaps we need a separate tutorial for scripters to
teach them how to properly combine the plumbing commands?
@Phillip thanks for your effort!
However, I must admit that for us, this cure is worse then the problem.
We're not exactly scrip
On 01.08.2019 17:56, Junio C Hamano wrote:
So, reading paths from a file (which could be "-" as you suggest)
would be a good solution for that.
To summarize:
1) Implement --paths-file for high-level commands.
2) '--paths-file -' would mean reading from stdin.
Is that something you're ready to
On 01.08.2019 16:26, René Scharfe wrote:
Would it make sense to have a --paths-file parameter instead
Both approaches (stdin or file) will work well for us. File sounds
easier from programming perspective. However, in previous discussion,
there was some concern about possible security problems
On 31.07.2019 19:19, Jeff King wrote:
I don't have any real objection to adding stdin support for more
commands. Bu tin the specific case you're discussing, it seems like
using "git update-index" might already solve your problem. It's the
intended plumbing for scripted index updates, and it alrea
Hello,
Hello,
This is a follow-up for previous discussion [1].
In our git UI, we sometimes run into OS commandline length limit when
trying to specify a list of pathspecs. For example, this happens when
user selects a large set of files and wants to commit them. As a
workaround, we split files
34 matches
Mail list logo
