Blob.lazy adds a blob to a batch to load at a later point, using the
BatchLoader library. Whenever any lazy blob's attributes are accessed,
all lazy blobs requested to that point will be loaded.
BatchLoader, the library we use for this, should only request items in a
batch once. That is, if we have these batches:
1. a, b, c
2. d, e, f
Then a, b, and c should only be requested in the first batch. But if you
modify the list of items in the batch, then the second batch will
request a, b, c, d, e, f, which is almost certainly not what we want!
https://github.com/exAspArk/batch-loader/issues/44 is the upstream issue
for this, but we can also solve this in our application by not modifying
the arguments we're using inside a BatchLoader batch.
This commit, introduced in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23812,
fixes a problem creating a displaying image diff notes when the image
is stored in LFS. The main problem was that `Gitlab::Diff::File` was
returning an invalid valid in `text?` for this kind of files.
It also fixes a rendering problem with other LFS files, like text
ones. They LFS pointer shouldn't be shown when LFS is enabled
for the project, but they were.
By specifying `key`, we get a different lazy batch loader for each
repository, which means that accessing a lazy object from one repository
will only result in that repository's objects being fetched, not those
of other repositories, saving us some unnecessary Gitaly lookups.
Sketch 43 files are technically a zip file, so the JavaScript opens the
zip file & locates a preview.png which is just a quick preview of the
last sketch page edited. After that is loaded it simply places the image
into the DOM
Do not display a 404, when a user tries to retrieve the raw content of
an LFS file (pointer) if the config option "lfs_enabled" is set to
false. Instead, display the LFS pointer file directly.
gitlab_git 10.6.4 relies on Rugged marking blobs as binary or not,
instead of relying on Linguist. Linguist in turn would mark text blobs
as binary whenever they would contain byte sequences that could not be
encoded using UTF-8.
However, marking such blobs as binary is not correct. If one pushes a
Markdown document with invalid character sequences it's still a text
based Markdown document and not some random binary blob.
This commit overwrites Blob#data so it automatically converts text-based
content to UTF-8 (the encoding we use everywhere else) while taking care
of replacing any invalid sequences with the UTF-8 replacement character.
The data of binary blobs is left as-is.
This ensures that SVGs greater than 2 megabytes are not scrubbed and
rendered. This in turn prevents requests from timing out due to
reading/scrubbing large SVGs potentially taking a lot of time (and
memory). The use of 2 megabytes is completely arbitrary.
Fixesgitlab-org/gitlab-ce#1435
This allows us to take advantage of Rails' `to_partial_path` to render
the correct partial based on the Blob type, rather than cluttering the
view with conditionals.
It also allows (and will allow in the future) better encapsulation for
Blob-related logic which makes sense for our Rails app but might not
make as much sense for the core `gitlab_git` library, such as detecting
if the blob is an SVG.