• Georges Racinet's avatar
    gitaly_client: plugging in HGitaly in CommitService · d3f9a208d676
    Georges Racinet authored
    This is more complicated than what we've done earlier for
    - Upstream passes down storage to `GitalyClient.call` as
      `@repository.storage`. We don't want to change all methods
      of CommitService because it wouldn't apply readily to new
      methods from upstream.
      Hence we actually re-instantiate `@repository`,
      with the VCS-qualified storage, with the new `vcs_storage_clone`
      method. On the side, this also requires a small change
      in HgGitRepository to make the value admissible.
    - only a subset of Commit service methods are actually involved
      in our first round of HGitaly implementation (getting rid of
      Git SHAs, see HGitaly1 milestone). We're deciding here that
      the other methods will use directly the original storage name,
      that we store as a new instance variable, `@git_storage`.
      In particular, we're trying to avoid the implementation of the
      various methods for Commit content (files, trees, diffs…) for
      the HGitaly1 milestone. This part is WIP (we'll need to
      convert back to Git revisions to complete it).
    - Finally, this hack also requires to make sure that the resulting
      Commit instances refer to the original Repository, so that further
      (H)Gitaly calls done from these Commits don't reuse a VCS-qualified
      storage, which would defeat the very purpose of separation.
    This is all very hacky. The only thing that makes it admissible is
    that it is temporary scaffolding. For the HGitaly2 milestone, all
    methods will go to HGitaly, and perhaps we can convince upstream to
    use a `@storage` instance variable here for the sake of uniformity.
    branch : heptapod