- Aug 04, 2021
-
-
Georges Racinet authored
-
- Aug 03, 2021
-
-
Georges Racinet authored
-
- Jul 19, 2021
-
-
Georges Racinet authored
Closes #55 Since we're only removing special refs, comparison to Gitaly has to be understood as assuming that only special refs will be removed on the Git side, which we arrange for directly.
-
Georges Racinet authored
This `assert_compare()` makes for shorter assertion lines, whose meaning is hopefully quicker to grasp.
-
Georges Racinet authored
This should distract readers a bit less.
-
Georges Racinet authored
This will make forthcoming code for `except_prefix` easier to integrate.
-
Georges Racinet authored
Although the `repository_service` comes from Gitaly itself (proto file name), if we strip it down from the class, let's also do it for the module name.
-
- May 28, 2021
-
-
Sushil Khanchi authored
-
- May 31, 2021
-
-
Sushil Khanchi authored
-
- May 15, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- May 13, 2021
-
-
Sushil Khanchi authored
-
- Jul 04, 2021
-
-
Georges Racinet authored
also adapted the Gitaly protocol upgrade procedure to avoid removing the HGitaly specific `proto` files. I don't honestly remember why this `rm` was there. Could have been general concern in case an upstream proto file actually has to disappear (not likely, we'll deal it manually if that happens)
-
Georges Racinet authored
The goal of this implementation is to validate that this HGitaly specific service can be called from the Rails app, using the generated HGitaly Ruby library. The provided `GetConfigItem` method works, but its implementation has to be completed with: - error treatment - `STRING` type case (the only one currently listed in the protocol)
-
Georges Racinet authored
First committed run of `generate-grpc-lib`
-
Georges Racinet authored
This is enough to install the generated lib locally and use it from the Rails application.
-
Georges Racinet authored
Our files layout differs from upstream's, because of the `hgitaly` package name, and also because we only care about the generated lib, whereas Gitaly also has Ruby code of its own. We also derive the version module directly from `hgitaly/version`
-
Georges Racinet authored
The `generate-proto-ruby` script and its supporting `run.rb` are pristine copies from Gitaly 13.12.2. They don't work for HGitaly at this point: this changeset is there to make application of upstream updates easier.
-
Georges Racinet authored
-
Georges Racinet authored
This is the first definition of Mercurial (or Heptapod) gRPC methods. It takes the form of a dedicated service, in a separate `hgitaly` protobuf package. ## About the separate package The protobufs `package` directive translates directly into a the module name in Ruby generated code. This doesn't happen with Python because Python modules and packages names are derived from the file system layout, wich is obviously out of control of the code generation. Upstream's Ruby generated code is packaged in a separate gem, historically from the `gitaly-proto` project, and soon to be built from the bundled proto files within Gitaly. We are not not going to fork either of those, and hence we need our own package. At some point, we may also need to generate a Go library, which require a `option go_package` statement that we couldn't provide right away because it means choosing the appropriate full path (see examples in upstream GitLab proto files). A consequence of using our own protobuf package for the declaration itself is that we need to reference the Gitaly types with their fully qualified name (`.gitaly.SomeType` in absolute form). Same applies to the options. References: - https://developers.google.com/protocol-buffers/docs/proto3#packages - https://developers.google.com/protocol-buffers/docs/proto#customoptions Quote: "Note that if you want to use a custom option in a package other than the one in which it was defined, you must prefix the option name with the package name, just as you would for type names." (example follows) ## About MercurialRepositoryService itself This service is for Mercurial specific methods that are considered to be global with respect to a given repository. It should cover the needs of #60 and #62 This follows the general Gitaly style: each method gets its own pair of request/response messages, even if that looks to be redundant. The main advantage should be to give unlimited room for future change that would introduce actual changes. Reference: https://gitlab.com/gitlab-org/gitaly/blob/master/proto/README.md#design-decisions
-
- Jul 05, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- May 31, 2021
-
-
Georges Racinet authored
In some cases this replaces existing logs with the more complete dump of the request. Again, it's not useful to put the name of the method in the message: the name of the request class fulfills that purpose easily.
-
Georges Racinet authored
We don't need to include the method name in the log message, because of the Gitaly protocol conventions: each method has its own, dedicated Request class, whose name is already part of the rendering.
-
- Jul 01, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Mar 21, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Mar 20, 2021
-
-
Sushil Khanchi authored
-
- Jun 17, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Seen for the the first time in GitLab 13.12 context, as in the new test. Probably a call somewhere that doesn't bother to check for emptiness first.
-
Georges Racinet authored
-
- Jun 16, 2021
-
-
Georges Racinet authored
-
- Jun 11, 2021
-
-
Georges Racinet authored
-
- May 26, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-