| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When passing start_branch on committing from the WebIDE, it's possible
that the branch has changed since editing started, which results in the
change being applied on top of the latest commit in the branch and
overwriting the new changes.
By passing the start_sha instead we can make sure that the change is
applied on top of the commit which the user started editing from.
|
|
This was done to perform some local testing, but while the change was
already made it made sense to commit the change.
|
|
Currently, MergeToRefService is specifically designed for
createing merge commits from source branch and target branch of
merge reqeusts. We extend this behavior to source branch and any
target ref paths.
|
|
When FindCommit ref caching is enabled, negative matches would
previously not be cached. However, if a source branch is deleted,
there's no need to keep looking up the same commit. This change caches
the result of a nil commit.
|
|
The feature flag has been introduced an was turned off by default,
now the it will default to be turned on. That change would still allow
users to turn this feature off by leveraging the Rails console by
running:
`Feature.disable("gitaly_catfile-cache")`
Another option is to manage the number of items the LRU cache will
contain, by updating the `config.toml` for Gitaly. This would be the
`catfile_cache_size`:
https://gitlab.com/gitlab-org/gitaly/blob/0dcb5c579e63754f557aef91a4fa7a00e5b8b127/config.toml.example#L27
Closes: https://gitlab.com/gitlab-org/gitaly/issues/1712
|
|
Fix UTF-8 conversion issues when resolving conflicts
Closes #63062
See merge request gitlab-org/gitlab-ce!29453
|
|
|
|
Similar to https://gitlab.com/gitlab-org/gitlab-ce/issues/63030,
when the commit message in the /resolve_conflicts endpoint contains a
UTF-8 character, the conversion to the Gitaly ASCII-8BIT value may flag
an error. To fix this, we run `force_encoding` on the commit message.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63062
|
|
|
|
CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13460
|
|
|
|
Remove cleaned up OIDs from database and cache
Closes #30093
See merge request gitlab-org/gitlab-ce!26555
|
|
|
|
DisconnectGitAlternates is a Gitaly RPC that will delete a repository's
objects/info/alternates file. This commit adds client support for that
RPC.
|
|
PackRefs is not an expensive gitaly call - we want to
call it more often (than as part of full `gc`) because
it helps to keep number of refs files small - too many
refs file may be a problem for deployments with
slow storage.
|
|
The new two-step Gitaly `Rebase` RPC yields the rebase commit SHA to the
client before proceeding with the rebase.
This avoids an issue where the rebase commit SHA was returned when the
RPC had fully completed, and in some cases this would be after the Rails
`post_receive` worker services had already run. In these situations,
the merge request did not yet have its rebase_commit_sha attribute set
introducing the possibility for bugs (such as previous approvals being
reset).
https://gitlab.com/gitlab-org/gitlab-ee/issues/5966
|
|
Gitaly's FetchIntoObjectPool RPC will idempotently fetch objects into an
object pool. If the pool doesn't exist, it will create an empty pool
before attempting the fetch. This change adds client code as well as
specs to cover this behavior.
|
|
Ensure that we only request blobs in one batch
Closes #60829
See merge request gitlab-org/gitlab-ce!27625
|
|
Updates the gitaly client to use path_bytes field instead of the
deprecated path field in list_last_commits_for_tree_response.
Also adds a test to guard against non-utf8 path data
|
|
Inside a wiki, when we show the sidebar or browse to the `pages`,
all page contents are retrieved from Gitaly and that is a waste
of resources, since no content from that pages are going to be
showed.
This MR introduces the method `ProjectWiki#list_pages`,
which uses new wiki_list_pages RPC call to retrieve
pages without content
Also in the `WikisController` we're using the method to show
pages in the sidebar and also on the `pages` page.
|
|
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.
|
|
FSCK is usually called through sidekiq, but a rake task doesn't have a
mechanism to default to no timeout for this RPC.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/53319
|
|
- Add controls for sorting by title and date
- Execute Gitaly call which now accepts sorting params for wikis
|
|
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/59777.
In earlier iterations of our implementation of Git object deduplication
we thought we would be making extensive use of Git remotes in pool
repositories in the future, and that we should manage these remotes
carefully from the start. We now expect we only care about one remote,
namely the source project. The other remotes are there only for forensic
purposes.
Before this MR we tried to also remove pool remotes when member projects
got deleted, with the UnlinkRepositoryFromObjectPool RPC. This is
fragile when there are race conditions (see
https://gitlab.com/gitlab-org/gitaly/issues/1568#note_153955926). We
have spent some time making this RPC less fragile in
https://gitlab.com/gitlab-org/gitaly/merge_requests/1151 but looking at
this problem again, I think we should just stop calling it.
|
|
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.
|
|
For a given merge request, it's quite common to see duplicate FindCommit
Gitaly requests because the Gitaly CommitService caches the request by
the commit SHA, not by the ref name. However, most of the duplicate
requests use the ref name, so the cache is never actually used in
practice. This leads to unnecessary requests that slow performance.
This commit allows certain callers to bypass the ref name to
OID conversion in the cache. We don't do this by default because it's
possible the tip of the branch changes during the commit, which
would cause the caller to get stale data.
This commit also forces the Ci::Pipeline to use the full ref name
so that caching can work for merge requests.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57083
|
|
Move EE specific code out of lib/gitlab
See merge request gitlab-org/gitlab-ce!25741
|
|
Remove timeout for GitalyClient remove_remote
Closes #56015
See merge request gitlab-org/gitlab-ce!26213
|
|
This can be slow because it must potentially remove a lot of remote
refs (if the remote being removed has a lot of refs)
|
|
|
