Read about our upcoming Code of Conduct on this issue

This instance was upgraded to Heptapod 0.28.0 today

  1. 04 Jul, 2021 4 commits
    • Georges Racinet's avatar
      Ruby library: adapted generating script · 438b0a4c7693
      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's avatar
      Ruby library: copy of upstream generating scripts · 40e11e7dc7ee
      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's avatar
      Ruby generated library: initial structure · c52e3be18244
      Georges Racinet authored
    • Georges Racinet's avatar
      MercurialRepositoryService, initial definition · c2b6480dbea2
      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
      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.
        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
      ## About MercurialRepositoryService itself
      This service is for Mercurial specific methods
      that are considered to be global with respect to a given
      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.
  2. 05 Jul, 2021 3 commits
  3. 31 May, 2021 2 commits
    • Georges Racinet's avatar
      CommitService logging all incoming requests · dcef6bbdc59a
      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's avatar
      RefService logging all incoming requests · 06e62bed644b
      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.
  4. 01 Jul, 2021 2 commits
  5. 21 Mar, 2021 2 commits
  6. 20 Mar, 2021 1 commit
  7. 17 Jun, 2021 5 commits
  8. 16 Jun, 2021 1 commit
  9. 26 May, 2021 5 commits
  10. 24 Apr, 2021 1 commit
  11. 22 Apr, 2021 11 commits
  12. 21 Apr, 2021 2 commits
    • Georges Racinet's avatar
      Blob service: streaming in chunks of WRITE_BUFFER_SIZE · 92c2deb0bf56
      Georges Racinet authored
      The reason why Gitaly does not respect `WRITE_BUFFER_SIZE`
      even though the Blob serving method go through its
      `streamio.SendWriter` object which enforces it is now
      roughly understood: the `SendWriter` object is called for
      the smaller chunks generated by `io.CopyN`.
      Since this does not look to be the actual intent in Gitaly
      and may be corrected later, we make HGitaly abide to
      `WRITE_BUFFER_SIZE` right away. This makes our code
      more consistent.
      Also, this makes the default chunk size go up from 16kB to
      128kB. It wouldn't be very surprising if the penalty for
      chunks that are too small (number of requests multiplied by 8)
      would be bigger in a Python program than in a Go program, because
      we may have a higher overhead per request.
    • Georges Racinet's avatar
      Gitaly Comparison tests: Gitaly Blob chunking can vary · 9e62dfcb2c9d
      Georges Racinet authored
      This fixes a flakiness in the comparison tests for `get_blob` and
      `get_blobs`: Gitaly's chunking is not constant, seems to depend
      on the (circumstantial) size of some inner buffers or similar.
      Hence a direct comparison of Gitaly and HGitaly responses is
      Instead, we are focusing on what matters: repetition of metadata
      like oid and size (or not) and of course that the whole content
      is correct.
  13. 22 Apr, 2021 1 commit