| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This should already be done in Gitlab::Git:Compare.
|
|
A temp reference is only needed to fetch a branch from another project,
as in the case for forked repositories. For branch comparisons within
the same project, we can just use the existing branch names to do the
comparison.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/38689#note_126107862
|
|
Bring back Rugged implementation of ListCommitsByOid
See merge request gitlab-org/gitlab-ce!27441
|
|
This brings back changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20432.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged may be faster than going through than Gitaly. This merge
request introduces the feature flag `rugged_list_commits_by_oid` to
activate the Rugged method.
For one customer, we saw that ListCommitsByOid was the second highest
used endpoint that may be causing increased load.
|
|
This reverts commit 171818df0a72097aa1a804c8213666b3f66b0966.
|
|
Revert "Merge branch '24704-download-repository-path' into 'master'"
See merge request gitlab-org/gitlab-ce!27249
|
|
This reverts commit 6c75bd015cba181f028bc87c396c3d8e43b5dc3e, reversing
changes made to 1be7f5aaa38aba79843eae8835be6c99c025e982.
|
|
|
|
- Add controls for sorting by title and date
- Execute Gitaly call which now accepts sorting params for wikis
|
|
Add `GetArchiveRequest` to git-archive params.
Modifies `Git::Repository#archive_metadata` to append `path`
to `ArchivePrefix` so it'll not hit the cache of repository archive
when it already exists.
|
|
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.
|
|
The Rugged implementation was recursively scanning the repository to
create `flat_path` because the post-process step was being called from
with a loop. For large repositories, this was significantly slowing
things down. Break the call to `rugged_populate_flat_path` out of this
loop to make this work efficiently.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/59759
|
|
Allow custom hooks errors to appear in GitLab UI
Closes #48132
See merge request gitlab-org/gitlab-ce!25625
|
|
'58805-allow-incomplete-commit-data-to-be-fetched-from-collection' into 'master'
Enrich commits with full data in CommitCollection
Closes #58805
See merge request gitlab-org/gitlab-ce!26445
|
|
Error messages from custom pre-receive hooks now appear in the GitLab
UI.
This is re-enabling a feature that had been disabled in merge request
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18646
The feature had been disabled due to security concerns that information
which was not intended to be public (like stack traces) would leak into
public view.
PreReceiveErrors (from pre-receive, post-receive and update custom
hooks) are now filtered for messages that have been prefixed in a
particular way.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/48132
|
|
Allow incomplete commit records to load their full data from gitaly.
Commits can be based on a Hash of data retrieved from PostgreSQL, and
this data can be intentionally incomplete in order to save space.
A new method #gitaly? has been added to Gitlab::Git::Commit, which
returns true if the underlying data source of the Commit is a
Gitaly::GitCommit.
CommitCollection now has a method #enrich which replaces non-gitaly
commits in place with commits from gitaly.
CommitCollection#without_merge_commits has been updated to call this
method, as in order to determine a merge commit we need to have parent
data.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/58805
|
|
'58805-allow-incomplete-commit-data-to-be-fetched-from-collection' into 'master'"
This reverts merge request !26144
|
|
'58805-allow-incomplete-commit-data-to-be-fetched-from-collection' into 'master'
Enrich commits with full data in CommitCollection
Closes #58805
See merge request gitlab-org/gitlab-ce!26144
|
|
Backport of avoid_es_loading_commits
See merge request gitlab-org/gitlab-ce!26301
|
|
|
|
Allow incomplete commit records to load their full data from gitaly.
Commits can be based on a Hash of data retrieved from PostgreSQL, and
this data can be intentionally incomplete in order to save space.
A new method #gitaly? has been added to Gitlab::Git::Commit, which
returns true if the underlying data source of the Commit is a
Gitaly::GitCommit.
CommitCollection now has a method #enrich which replaces non-gitaly
commits in place with commits from gitaly.
CommitCollection#without_merge_commits has been updated to call this
method, as in order to determine a merge commit we need to have parent
data.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/58805
|
|
EE added the ability to set timeouts when handling blobs. Since there's
no particular reason for this to be EE specific we can just backport
this to CE.
|
|
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20176/diffs.
We discovered another N+1 that hits Gitaly `TreeEntry` via the
`RelativeLinkFilter`:
https://gitlab.com/gitlab-org/gitlab-ce/issues/58657. When a blob is
loaded with many relative links, `TreeEntry` is called for each link to
scan the URI type.
There are multiple paths that hit Gitaly `TreeEntry`, and
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25706 did not
cover all cases. This commit covers another common use case.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged may be faster than going through than Gitaly. This merge
request introduces the feature flag `rugged_commit_tree_entry` to
activate the Rugged method.
|
|
Bring back Rugged implementation of TreeEntry
See merge request gitlab-org/gitlab-ce!25706
|
|
|
|
|
|
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20099/diffs
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_tree_entry` to activate the Rugged method.
Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.
|
|
|
|
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20343.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_tree_entries` to activate the Rugged method.
Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.
|
|
Bring back Rugged implementation of CommitIsAncestor
See merge request gitlab-org/gitlab-ce!25702
|
|
This style change enforces `return if ...` instead of
`return nil if ...` to save maintainers a few minor review points
|
|
When `force` is set to `true` and `start_branch` is set, the
branch will be ovewritten with the new commit based on the
`HEAD` of the `start_branch`.
This commit includes changes to update the `gitaly-proto` gem.
|
|
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20095.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_commit_is_ancestor` to activate the Rugged
path.
Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.
|
|
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20339.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_find_commit` to activate Rugged paths.
There are also Rake tasks `gitlab:features:enable_rugged` and
`gitlab:features:disable_rugged` to enable/disable these feature
flags altogether.
Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.
|
|
Adds the ground work for writing into
the merge ref refs/merge-requests/:iid/merge the
merge result between source and target branches of
a MR, without further side-effects such as
mailing, MR updates and target branch changes.
|
|
Adds the client call for the gitaly rpc CountDivergingCommits
fixing signature
simplifying commit logic
adding test for max-count
refactoring tests
|
|
Upgrade gitaly-proto to 1.10.0 to have this field.
|
|
When hashed storage is in use, it's helpful to have the project
name associated with the request.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1394
|
|
|
|
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.
|
|
Leave object pools when destroying projects
Closes gitaly#1415
See merge request gitlab-org/gitlab-ce!23869
|
|
This action doesn't lean on reduplication, so a short call can me made
to the Gitaly server to have the object pool remove its remote to the
project pending deletion.
https://gitlab.com/gitlab-org/gitaly/blob/f6cd55357/internal/git/objectpool/link.go#L58
When an object pool doesn't have members, this would invalidate the need
for a pool. So when a project leaves the pool, the pool will be
destroyed on the background.
Fixes: https://gitlab.com/gitlab-org/gitaly/issues/1415
|
|
This upgrade moves logic from gitlab-rails to Gitaly, which allowed code
removal too.
|
|
When a project is forked, the new repository used to be a deep copy of everything
stored on disk by leveraging `git clone`. This works well, and makes isolation
between repository easy. However, the clone is at the start 100% the same as the
origin repository. And in the case of the objects in the object directory, this
is almost always going to be a lot of duplication.
Object Pools are a way to create a third repository that essentially only exists
for its 'objects' subdirectory. This third repository's object directory will be
set as alternate location for objects. This means that in the case an object is
missing in the local repository, git will look in another location. This other
location is the object pool repository.
When Git performs garbage collection, it's smart enough to check the
alternate location. When objects are duplicated, it will allow git to
throw one copy away. This copy is on the local repository, where to pool
remains as is.
These pools have an origin location, which for now will always be a
repository that itself is not a fork. When the root of a fork network is
forked by a user, the fork still clones the full repository. Async, the
pool repository will be created.
Either one of these processes can be done earlier than the other. To
handle this race condition, the Join ObjectPool operation is
idempotent. Given its idempotent, we can schedule it twice, with the
same effect.
To accommodate the holding of state two migrations have been added.
1. Added a state column to the pool_repositories column. This column is
managed by the state machine, allowing for hooks on transitions.
2. pool_repositories now has a source_project_id. This column in
convenient to have for multiple reasons: it has a unique index allowing
the database to handle race conditions when creating a new record. Also,
it's nice to know who the host is. As that's a short link to the fork
networks root.
Object pools are only available for public project, which use hashed
storage and when forking from the root of the fork network. (That is,
the project being forked from itself isn't a fork)
In this commit message I use both ObjectPool and Pool repositories,
which are alike, but different from each other. ObjectPool refers to
whatever is on the disk stored and managed by Gitaly. PoolRepository is
the record in the database.
|
|
|
|
Use shelling out to git to write refs instead of rugged, hoping to
avoid creating invalid refs.
To update HEAD we switched to using `git symbolic-ref`.
|
|
|
|
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.
|
|
Revert "Merge branch 'revert-e2aa2177' into 'master'"
Closes #54267
See merge request gitlab-org/gitlab-ce!23237
|
