-
Georges Racinet authored
This is more complicated than what we've done earlier for `RefService`: - 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.
d3f9a208d676