Commit Graph

19 Commits

Author SHA1 Message Date
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