GitLab Bot
aea64c367b
Add latest changes from gitlab-org/gitlab@master
2021-09-06 09:11:02 +00:00
GitLab Bot
4a6e6c740b
Add latest changes from gitlab-org/gitlab@master
2021-07-23 18:10:06 +00:00
GitLab Bot
25db9c1230
Add latest changes from gitlab-org/gitlab@master
2021-05-06 12:10:38 +00:00
GitLab Bot
bdca097916
Add latest changes from gitlab-org/gitlab@master
2020-08-11 03:11:00 +00:00
GitLab Bot
c59765a50a
Add latest changes from gitlab-org/gitlab@master
2020-06-24 18:09:03 +00:00
GitLab Bot
f1a40d0db9
Add latest changes from gitlab-org/gitlab@master
2020-03-09 15:07:45 +00:00
GitLab Bot
80f61b4035
Add latest changes from gitlab-org/gitlab@master
2019-09-18 14:02:45 +00:00
GitLab Bot
bd860c22f6
Add latest changes from gitlab-org/gitlab@master
2019-09-17 12:06:48 +00:00
Thong Kuah
d9db8d85b3
Fix cannot modify frozen string
...
Note that Performance/UnfreezeString recommends unary plus over
"".dup, but unary plus has lower precedence so we have to use
parenthesis
2019-07-26 13:25:07 +12:00
Thong Kuah
f540ffcef6
Add frozen_string_literal to spec/lib (part 1)
...
Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
2019-07-26 13:25:07 +12:00
Bob Van Landuyt
8c5b3d0302
Allow streaming io objects into Gitaly
...
This allows us to set the encoding of an IO passed without reading it
into memory.
This is useful if we want to stream files into Gitaly. Like we do when
uploading a new file to the repository.
2019-04-01 20:17:40 +02:00
blackst0ne
236876f278
Update specs to exclude possible false positive pass
2018-12-18 10:21:30 +11:00
Stan Hu
038be9fffa
Fix Error 500s due to encoding issues when Wiki hooks fire
...
Saved Wiki content goes through the GitalyClient::WikiService, which calls
StringIO#set_encoding on the input stream. The problem is that this call
mutates the encoding of the given string object to ASCII-88BIT, which
causes problems for models expecting the data to still be in UTF-8.
Freezing the input disables this behavior:
https://github.com/ruby/ruby/blob/v2_4_4/ext/stringio/stringio.c#L1583
Closes #50590
2018-08-29 09:46:46 -07:00
Ahmad Sherif
1f2cc29c8f
Fix EncodingHelper#clean blowing up on UTF-16BE strings
...
Closes gitaly#1101
2018-03-22 21:22:20 +01:00
Ahmad Sherif
0d9107374a
Return a warning string if we try to encode to unsupported encoding
...
Fixes gitlab-development-kit#321
2018-02-09 22:19:43 +01:00
Alejandro Rodríguez
5152cc3bfb
Fix a bug where charlock_holmes was used needlessly to encode strings
2018-01-04 19:27:37 -03:00
Alejandro Rodríguez
11247ac97c
Move encoding methods to the more general EncodingHelper
2017-12-28 12:32:33 -03:00
Jacob Vosmaer (GitLab)
4cfcc97544
Fix encoding bugs in Gitlab::Git::User
2017-11-23 10:48:57 +00:00
Alejandro Rodríguez
520866a0d0
Avoind unnecesary `force_encoding` operations
...
They're costly. This will also avoid some edge cases where
charlock_holmes assigns a weird encoding to a perfectly valid UTF-8
string.
2017-10-18 21:30:29 -03:00
Lin Jen-Shin
75096f958c
Make sure that we have author and committer
...
In case we don't have it setup in ~/.gitconfig
2017-08-08 20:35:38 +08:00
Lin Jen-Shin
d831e8e1d0
Add a test to show that threshold 40 would corrupt
...
If we set `ENCODING_CONFIDENCE_THRESHOLD` to 40,
this test case would not pass. If we raise to 50,
this would pass.
Note that if in the future rugged didn't return
corrupt data, this would be less relevant. But still
icu recommend the threshold to be 50, we should just
stick with 50.
2017-08-08 19:10:46 +08:00
Bob Van Landuyt
e564fe971f
Rename `Gitlab::Git::EncodingHelper` to `Gitlab::EncodingHelper`
2017-06-01 21:21:14 +00:00