We request Gitaly in a N+1 manner to build discussion diffs. Once the diffs are from different revisions, it's hard to make a single request to the service in order to build the whole response.
With this change we solve this problem and simplify a lot fetching this piece of info.
This adds a method to track errors that can be recovered from in
sentry.
It is useful when debugging performance issues, or exceptions that are
hard to reproduce.
Previously, we kept them all in the cache. We don't need the highlight results
for older diffs - if someone does view that (which is rare), we can do the
highlighting on the fly.
Rugged sometimes chops a context line in between bytes, resulting in the context
line having an invalid encoding: https://github.com/libgit2/rugged/issues/716
When that happens, we will try to detect the encoding for the diff, and
sometimes we'll get it wrong. If that difference in encoding results in a
difference in string lengths between the diff and the underlying blobs, we'd
fail to highlight any inline diffs, and return a 500 status to the user.
As we're using the underlying blobs, the encoding is 'correct' anyway, so if the
string range is invalid, we can just discard the inline diff highlighting. We
still report to Sentry to ensure that we can investigate further in future.
Due to the refactoring in !16082, `Blob#batch` no longer falls back
to a default `blob_size_limit`. Since `Repository#batch_blobs` was using
a default `nil` value, this would cause issues in the `Blob#find_by_rugged`
method.
This fix here is to be consistent and use a non-nil default value in
`Repository#batch_blobs`.
The problem was masked in development and tests because Gitaly is always
enabled by default for all features.
Closes#41735
Old merge requests can have diffs without corresponding blobs. (This also may be
possible for commit diffs in corrupt repositories.)
We can't use the `&.` operator on the blobs, because the blob objects are never
nil, but `BatchLoader` instances that delegate to `Blob`. We can't use
`Object#try`, because `Blob` doesn't inherit from `Object`.
`BatchLoader` provides a `__sync` method that returns the delegated object, but
using `itself` also works because it's forwarded, and will work for
non-`BatchLoader` instances too. So the simplest solution is to just use that
with the `&.` operator.
If a merge request was created with a branch name that also matched a tag name,
we'd generate a comparison to or from the tag respectively, rather than the
branch. Merging would still use the branch, of course.
To avoid this, ensure that when we get the branch heads, we prepend the
reference prefix for branches, which will ensure that we generate the correct
comparison.
For some old merge requests, we don't have enough information to figure out the
old blob and the new blob for the file. This means that we can't highlight the
diff correctly, but we can still display it without highlighting.
* upstream/master:
Ensure we have a project with a repo in GitlabMarkdownHelper specs
Revert "Make sure TraceReader uses Encoding.default_external"
Make sure TraceReader uses Encoding.default_external
Update CONTRIBUTING.md after merging "up-for-grabs" and "Accepting Merge Requests" [ci skip]
Use `:empty_project` where possible in finder specs
Use `empty_project` where possible in controller specs
Use `:empty_project` where possible in helper specs
Don’t count tasks that are not defined as list items correctly
Use a project factory with a repository where necessary
Use `:empty_project` where possible throughout spec/lib
Use hashrocket for dasherized attribute
Remove markdown file extension and add anchor to link
Fixed builds info link on project settings page
Factories with a project association use `:empty_project` by default
Update enviroments.md the example for deleting an environment is missing the "s" in environments. curl --request DELETE --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" "https://gitlab.example.com/api/v3/projects/1/environments/1" wil 404
Steps to reproduce:
1. Start with a repo with an image
2. Add a commit to delete the image
3. Add another commit to replace the image with another image
In a diff comparison, we really just compare about what the image was before the diff, not
the direct parent of the last commit. This MR fixes that.
Closes#3893, gitlab-org/gitlab-ee#678
Signed-off-by: Rémy Coutable <remy@rymai.me>
1. When a merge request is being merged, save the merge commit SHA in
the `in_progress_merge_commit_sha` database column.
2. The `pre-receive` hook looks for any locked (in progress) merge
request with `in_progress_merge_commit_sha` matching the `newrev` it
is passed.
3. If it finds a matching MR, the merge is legitimate.
4. Update `git_access_spec` to test the behaviour we added here. Also
refactored this spec a bit to make it easier to add more contexts / conditions.
Oswaldo Ferreira
Bob Van Landuyt
Sean McGivern
Stan Hu
Martin Nowak
Zeger-Jan van de Weg
AlexWayfer
Sean McGivern
Valery Sizov
Alejandro Rodríguez
Felipe Artur
Douwe Maan
Jacob Vosmaer
Jarka Kadlecova
Robert Speicher
Rémy Coutable
Robert Speicher
Douwe Maan
mhasbini
dixpac
Lin Jen-Shin
Paco Guzman
http://jneen.net/
Timothy Andrew
Grzegorz Bizon
Yorick Peterse
Rubén Dávila
Jacob Vosmaer
Dmitriy Zaporozhets
Jeroen van Baarsen