Skip to content
Snippets Groups Projects
  1. Jun 27, 2020
  2. Jun 28, 2020
    • Georges Racinet's avatar
      default branch: warning if fallback to the hardcoded default · 90fe8375
      Georges Racinet authored
      With the updating logic in `py-heptapod` and in the Rails app,
      we should never have to fallback to the hardcoded `branch/default`,
      except maybe on empty repos.
      
      Of course future migration of `hg_git` projects to `hgitaly` project
      will copy over the default branch information from the auxiliary
      Git repo to the Mercurial repo.
      90fe8375
    • Georges Racinet's avatar
      default branch: GitLab expects a ref · 740a9978
      Georges Racinet authored
      Despite its name, `FindDefaultBranchName` is actually expected
      to return a branch ref instead of a branch name.
      
      Given something else than a branch ref, the Rails app
      `Gitlab::Git.branch_name` returns `nil` (as of GitLab 12.10)
      740a9978
  3. Jun 23, 2020
  4. Jun 20, 2020
    • Georges Racinet's avatar
      (very partial) ref service: FindTag and FindAllTag · 16776923
      Georges Racinet authored
      This is partial because we don't have at the moment a clear way to
      get the commit responsible for the tag value, which would be
      needed to provide authorship and tag contents.
      
      In `mercurial.tags`, what is called `hist` is a list of previous
      tag *values*, hence is not what we need.
      
      Trying to reproduce the tag resolution logic, even with knowledge of
      the target changeset looks to be at best risky.
      
      Efficient extraction of that information would probably entail doing
      it along the target node information, and probably more caching.
      16776923
    • Georges Racinet's avatar
      ref service: updated comment about tags · 2ddf34a6
      Georges Racinet authored
      - decided to use the 'SPEC' marker wherever what's expected is
        not clear. Does not imply a formal specification can really
        be found.
      - tagtype() uses caches, so the comment was either obsolete
        or overblown.
      2ddf34a6
  5. Jun 23, 2020
    • Georges Racinet's avatar
      ref service: PackRefs · 5081b184
      Georges Racinet authored
      of course it does nothing. Contrary to `ListNewCommits`,
      calling it is not a hard error, as calling it by mistake
      is somewhat harmless (less critical than pre-receive checks).
      5081b184
    • Georges Racinet's avatar
      ref service: ListNewCommits/ListNewBlobs not relevant · f3297135
      Georges Racinet authored
      All explained in the docstrings, we probably never will
      implement them for Mercurial. On the client side, all
      currently existing callers must be rewritten
      anyway.
      f3297135
    • Georges Racinet's avatar
      ref service: ListTagNamesContainingCommit · 043d62f1
      Georges Racinet authored
      Same as sibling method for branches, we'll have to cope with
      ordering, but that can probably wait.
      043d62f1
    • Georges Racinet's avatar
      ref service: ListBranchNamesContainingCommits · b1dc70f8
      Georges Racinet authored
      At this point, the ordering of results is arbitrary.
      We don't expect that to be a problem until after the
      first end-to-end experiments.
      
      Implicitely expected ordering is specified in comment.
      
      Implementation is probably somewhat inefficient. It's a bit
      frustrating that in Mercurial we know right away to which
      branch a commit relates (contrary to Git) but still have to
      do all these ancestry computations.
      
      But it would be easy to be wrong if trying to be smarter.
      b1dc70f8
    • Georges Racinet's avatar
      util.chunked: with limits · 3346666b
      Georges Racinet authored
      This is a simple way to limit the number of items in responses,
      although we expect many cases to actually be better implemented
      by passing the limit down to the thing that produces the iterable
      being chunked
      3346666b
  6. Jun 20, 2020
  7. Jun 19, 2020
    • Georges Racinet's avatar
      ref service: reordering to match the proto file · 3648a95f
      Georges Racinet authored
      It's always been the intent, but some drift occurred due to
      `FindBranch` being way after `FindAllBranches`.
      3648a95f
    • Georges Racinet's avatar
      ref service: FindAllRemoteBranches · 0adfcb6f
      Georges Racinet authored
      In this first implementation, that's easy: there is no concept
      of remote branches in Mercurial.
      
      Although, on second thought, in GitLab they could be related to
      mirroring features, and we may need to have something similar
      for Mercurial at some point which would be provided by an extension,
      that we'd write ourselves if it doesn't exist already.
      0adfcb6f
    • Georges Racinet's avatar
      ref service: FindLocalBranches · bf7abe24
      Georges Racinet authored
      It looks as if the `commit` field was added last, and that
      would explain why the redundancy.
      bf7abe24
    • Georges Racinet's avatar
      Support multiple storages · 5cca85c5
      Georges Racinet authored
      This was left aside in the project bootstrap.
      We won't actually need multiple storages for a while, hence
      the server command still uses a single `repositories-root`.
      
      But we better have the internals support multiple storages right
      away: its easier to do right now than to add it afterwards.
      5cca85c5
  8. Jun 18, 2020
    • Georges Racinet's avatar
      ref service: FindBranch and FindAllBranches · 4917ed9d
      Georges Racinet authored
      As the comment in test says, using `branch=None` translates
      in an actual `Branch` message with empty `name`, and this
      has been checked to be the proper representation for "lack
      of branch": gRPC doesn't have null/nil/None, using default
      values instead (reminescent of String rules in Golang).
      4917ed9d
  9. Jun 17, 2020
  10. Jun 18, 2020
  11. Jun 17, 2020
Loading