| Age | Commit message (Collapse) | Author |
|---|
|
Populating flat paths for large trees may be expensive
Let's add an option to skip it (to preserve the default behaviour)
in order to be able to avoid this expensive operation when it's
not necessary
Changelog: added
|
|
This commit changes the major version in the package name from v14 to
v15
Updating go.mod & go.sum with new module name v15
Update Makefile to bump major version to v15
Update the gitaly package name in the Makefile. Also update
gitaly-git2go-v14 -> gitaly-git2go-v15. We need to keep
gitaly-git2go-v14 for a release however, for zero downtime upgrades.
This pulls directly from a sha that is v14.
Update package name from v14->v15 for auth, client, cmd, internal packages
This commit changes the package name from v14 to v15 in go and proto
files in the internal, auth, client, cmd packages.
proto: Update major package number in package name
tools: Change major version number in package name from v14 to v15
gitaly-git2go: Change the package name from v14 to v15
update module updater for v15
Update the documentation for the module updater to reflect v15
|
|
Extended ListCommits to support filter by commit message
See merge request gitlab-org/gitaly!4421
|
|
Now that we are trying to extend ListCommits rpc of CommitService to
include various cases. It's updated to include functionality provided
by CommitsByMessage rpc and also support regex ignore case flag.
Changelog: changed
|
|
Our enumerations do not currently have any strict design guidelines.
This brings two issues with it:
1. Enumeration values are scoped per-service. Consequentially, if
two enumerations want to declare a value with the same name, the
declarations will clash.
2. It is not possible to discern the case where a caller hasn't set
the value of an enumeration at all versus the case where the
field was explicitly set to its zero-value.
The official Protobuf style guide thus says that enum values should
always be prefixed with the name of the enum itself, and that the zero
value should be called `UNSPECIFIED`. Let's enforce this style via
protolint so that any new enumerations will follow this recommendation.
|
|
Enforce that message fields must have a comment and add a placeholder
for all instances where such a comment is missing.
|
|
Enforce that enum fields must have a comment and add a placeholder for
all instances where such a comment is missing.
|
|
Enforce that enum definitions must have a comment and add a placeholder
for all instances where such a comment is missing.
|
|
Enforce that message definitions must have a comment and add a
placeholder for all instances where such a comment is missing.
|
|
Enforce that RPC definitions must have a comment and add a placeholder
for all instances where such a comment is missing.
|
|
Enforce that services must have a comment and add a placeholder for all
instances where such a comment is missing.
|
|
The `CheckObjectsExist()` RPC is a streaming RPC: the caller may send
one or more requests to check sets of revisions. This is done such that
this RPC call also works in the context where millions of revisions need
to be checked in a single call, which could otherwise exceed the gRPC
memory limitations.
The current behaviour is a tad weird though: revisions sent as part of
the initial request are completely ignored. This doesn't feel right as
the caller would now be forced to _always_ send at least two messages.
It's also not documented to be the case, and last but not least all our
other streaming RPCs don't do it this way either.
So let's fix this behaviour and also honor revisions sent of the initial
request.
Changelog: fixed
|
|
|
|
When pushing commits to a repository, access checks are run. In order to
use the quarantine directory, we need a way to filter out revisions that
a repository already has in the case that a packfile sends over objects
that already exists on the server. In this case, we don't need to check
the access.
Add an RPC that when given a list of revisions, returns the ones that
already exist in the repository, and the ones that do not exist in the
repository.
Changelog: added
|
|
|
|
The CommitsBetween RPC has been deprecated in favor of ListCommits,
which is a more flexible alternative. Rails has been converted to
ListCommits in f1f39db10ee (Use the ListCommits RPC for
Gitlab::Git::Commit.between, 2021-08-05) already, and with 96717bb
(gitaly: Convert from CommitsBetween to ListCommits, 2021-11-12) the
last existing callsite was removed from the Elasticsearch indexer.
Remove the RPC call completely.
Changelog: removed
|
|
The ListNewCommits RPC used to list all commits which were returned by
`git rev-list $newrev --not --all`, that is all commits which aren't
referenced by any existing ref. This RPC was replaced by ListCommits,
which is a lot more flexible and allows passing an arbitrary number of
revisions, including pseudo-refs "--not" and "--all". Downstream has
been converted in e8a98485fe7 (ff: Remove `:list_commits` feature flag,
2021-07-23) to exclusively use ListCommits, so ListNewCommits is now
unused.
Remove ListNewCommits.
Changelog: removed
|
|
If a page limit larger than 0 is set, this RPC will only retrieve that
number of entries from the list.
If a page token is set, this RPC will return entries after this OID.
This reduces the amount of recursive calls needed to flatten a path.
Relates to https://gitlab.com/gitlab-org/gitaly/-/issues/2704
Changelog: added
|
|
The GitLab frontend first makes a `GetTreeEntries` request to get a list
of all entries in the repository directory, and then it follows up with
a `ListLastCommitsForTree` request to fill in the last commit for each
entry.
If we paginate the `GetTreeEntries` RPC, we need to make sure that the
pagination matches the list returned by `ListLastCommitsForTree`. To do
this, we introduce a sort parameter in the `GetTreeEntries` that will
optionally return the entries, sorted by trees, blobs, and submodules.
Note that `GetTreeEntries` and `ListLastCommitsForTree` could possibly
be refactored to share the `git ls-tree` parsing, but they currently
have their own implementations. Also if `recursive` is used, the entries
will be sorted with trees first, but this should be okay since the
frontend doesn't request a recursive list for either RPC.
Relates to https://gitlab.com/gitlab-org/gitaly/-/issues/3700
Changelog: added
|
|
Implement a new parameter for the `ListCommits()` RPC which allows the
caller to list commits in reverse order.
Changelog: added
|
|
Implement a new `ListAllCommits()` RPC. In contrast to the existing
RPCs, this new RPC will list all commits part of the object database,
regardless of whether the objects are reachable or not. This is done via
git-cat-file(1)'s `--batch-all-objects` switch, which simply enumerates
all objects.
The intent of this RPC is not to list commits of the "main" object
database though, but instead to list commits which have just been
received via git-receive-pack(1). Objects which have been received like
this are first put into a quarantine directory such that they do not end
up in the repository when a push gets rejected. With this new RPC, we
can thus efficiently enumerate all commits part of a push without having
to traverse the object graph.
Changelog: added
|
|
Implement a new `ListCommits()` RPC. In contrast to the existing RPCs,
this one accepts a set of revisions including the pseudo-revisions
"--not" and "--all". This design is much more flexible compared to the
currently existing RPCs and is thus slated to deprecate a bunch of them.
Changelog: added
|
|
The new "v14" version of the Gitaly module is named to match
the next GitLab release. The module versioning is needed in
order to pull gitaly as a dependency in other projects. The
change updates all imports to include v14 version. The go.mod
file was modified as well after go mod tidy execution. And
the changes in dependency licenses are reflected in the NOTICE
file.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3177
|
|
When clients want the commits in a certain range, there's usually no
information available for them about how many commits are in this range.
The server will than parse and send commits as long as the client is
interested in them.
This change allows the client to signal how many commits at most the
server should send. It leverages the PaginationParameters structure as
previously exposed and used.
Requested as feature in: https://gitlab.com/gitlab-org/gitlab/-/issues/195667
|
|
Amend the code added in 3236114ad (Parse Git commit trailers when
processing commits, 2020-11-26) so we only parse the trailers if it's
requested of us.
This effectively implements a version of what I suggested in the
original MR for it at
https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2842#note_461990291
Since then Yorick opened a MR to use this data on the gitaly side:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49243 as well as
a higher-level UX MR:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50063
That code clears up the "why do we need to do this work for everything
that uses find_commits" question I had on the original MR, it seems we
really don't, and the combination of this MR and changing the 1st MR
to gitlab.git to have this in app/finders/commits_with_trailer_finder.rb:
diff --git a/app/finders/commits_with_trailer_finder.rb b/app/finders/commits_with_trailer_finder.rb
index 5b8c1faec1a..1579b0df35f 100644
--- a/app/finders/commits_with_trailer_finder.rb
+++ b/app/finders/commits_with_trailer_finder.rb
@@ -73,6 +73,6 @@ def each_page(trailer)
def fetch_commits(offset = 0)
range = "#{@from}..#{@to}"
- @project.repository.commits(range, limit: @per_page, offset: offset)
+ @project.repository.commits(range, limit: @per_page, offset: offset, trailers: true)
end
end
Will save us and /usr/bin/git the work of parsing these out every
time, only for the caller to not care about the data except in this
one case.
|
|
|
|
Last release, in
https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2269, the response
struct got updated to better correlate the input with the output. After
that, a proto field was deprecated. Given we're in a new release now,
it's safe to remove.
Fixes: https://gitlab.com/gitlab-org/gitaly/-/issues/2864
|
|
|
|
Files that contained glob characters (e.g. `:wq`) would not be viewable
in GitLab because Gitaly attempted to use the path as a search pattern
instead of interpreting the tree as a literal pathname. Just as we fixed
this in https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2285 for
LastCommitForPath, we need to add support for passing the Git
`--literal-pathspecs` argument for the following RPCs:
1. FindCommits
2. CommitsByMessage
3. CountCommits
|
|
Directories that contained glob characters (e.g. `:wq`) would not be
viewable in GitLab because Gitaly attempted to use the path as a search
pattern instead of interpreting the tree as a literal pathname. Just as
we fixed this in
https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2285 for
LastCommitForPath, we need to add support for passing the Git
`--literal-pathspecs` argument for LastCommitsForTreeRequest.
Closes https://gitlab.com/gitlab-org/gitaly/-/issues/2888
|
|
By default, we assume the pathspec is a glob spec, but there is now a
boolean field in the protobuf to add the --literal-pathspecs argument.
Changes to GitLab Rails will be needed to use this field to fix
https://gitlab.com/gitlab-org/gitaly/-/issues/2857.
This restores the changes in
https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2271 that were
reverted in https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2282,
but now the boolean flag allows the caller decide which mode to
use. Apparently GitLab was using the ListCommitForPath parameter as a
glob spec when computing a hash of a pipeline cache key
(https://gitlab.com/gitlab-org/gitlab/-/issues/222356).
|
|
|
|
|
|
Extracting lint-related stuff into separate proto file. It
is required in order to have proper working proto-linter.
Previously it was using compiled files for verification and
it fails in some cases
(https://gitlab.com/gitlab-org/gitaly/-/jobs/459024976).
lint.proto extracted from shared.proto and contains
lint-related declarations. New task `proto-lint` added to
compile source code that is required by `protoc-gen-gitaly`.
`protoc-gen-gitaly` fixed to use proper proto source data.
Regeneration of all proto-related files.
|
|
Instead of setting OID in the RPC method use annotation in the field
(`target_repository` and `additional_repository`). Having only this 2
annotations created a problem with messages that can be either target
or additional repository (for example `ObjectPool`). Those are marked
with `repository` annotation and `target_repository` and
`additional_repository` are used in the parent messages.
Signed-off-by: Mateusz Nowotyński <maxmati4@gmail.com>
Signed-off-by: jramsay <maxmati4@gmail.com>
|
|
Implement FindCommitsRequest with order argument to find commits
using git log --topo-order.
|
|
Adds an author field to the RPC message, which we pass along into the
--author=<pattern> argument in the git log command to find commits
filtered with that author pattern.
|
|
This RPC was introduced in 0.70.0, but gone unused in favour of the
GetCommitSignatures RPC. Given there's no active callsight, it's being
removed in GitLab-Rails too: https://gitlab.com/gitlab-org/gitlab/merge_requests/18804
Closes: https://gitlab.com/gitlab-org/gitlab/issues/31079
|
|
This change extends the CommitLanguage response to include FileCount and
Bytes. Getting the FileCount per language requires an additional
git-linguist call which might increase the GRPC call execution time.
To have control over the FileCount call, a new feature flag
('linguist_file_count_stats') has been introduced that can be turned off
when performance issues occur.
|
|
|
|
|
|
|
