Skip to content
Snippets Groups Projects
  1. Nov 26, 2020
  2. Nov 25, 2020
  3. Nov 22, 2020
  4. Nov 20, 2020
  5. Nov 22, 2020
  6. Nov 20, 2020
  7. Nov 19, 2020
  8. Nov 17, 2020
    • Georges Racinet's avatar
      branch: filtering obsolete heads · 5360f8ad
      Georges Racinet authored
      Same thing that our current hg-git conversion does, *but* this
      is known to have performance issues on large repositories. Putting
      this on a call path that the client has every right to think is cheap
      is very problematic.
      
      I would prefer a simple rule that Heptapod never exposes any obsolete
      head in its branch queries. The rationale for that would be that
      by definition Git does not either present any unreachable commit.
      
      For the time being (Heptapod 0.17), the projects backed by HGitaly are
      highly experimental, so we can probably live with it.
      5360f8ad
  9. Nov 18, 2020
    • Georges Racinet's avatar
      GitLab default branch: using an empty default when not set yet · 3a01705d
      Georges Racinet authored
      As the comment explains, this is for now the only way to let
      the Rails app actually know that the default branch hasn't been
      set yet.
      
      After a lot of defaultings in the applicative code, this eventually
      activates the code that's responsible for actually setting it while
      receiving the first push.
      
      We can do something much more robust and maintainable, but that
      will be after the first push. Meanwhile, we do have functional
      tests about that to cover our backs.
      3a01705d
    • Georges Racinet's avatar
      branch: don't let bookmarks shadow the default GitLab branch · b9889983
      Georges Racinet authored
      We introduce a flag in the inner function that sorts out what
      to do of the branchmap entries, and use it for the default GitLab
      branch only.
      
      As the test demonstrates, the default GitLab branch will still
      point to the latest bookmarked head, which is consistent with
      what happens with "wild" multiple heads.
      
      This is a minor change of behaviour compared to the Heptapod
      standard, in which the default GitLab branch would not move in
      that case. The reason is that we don't have a natural support to
      store the previous position of the default GitLab branch.
      Of course hg-git based repositories have/had this extra state, in
      the form of the actual Git branch. The new behaviour is not worse
      and as much arbitrary as the previous one, and will of course
      be matched by py-heptapod's mirrorring to Git.
      b9889983
  10. Nov 17, 2020
    • Georges Racinet's avatar
      revision: GitLab branches given in full ref form · 9abda71b
      Georges Racinet authored
      In many cases, the client will send revision specification
      also in ref form, e.g, `refs/heads/branch/default`. We
      were already resolving branch names and tags, now we have to
      support this, too.
      
      We should do something similar about tags
      9abda71b
    • Georges Racinet's avatar
      Commit: lookup methods have to work with obsolete · 71abb991
      Georges Racinet authored
      The Rails app will store some changeset IDs and get back to HGitaly
      for information after a while. For instance, this is what happens
      with Merge Requests. It's perfectly possible that the changeset has
      become obsolete in the mean time.
      
      Hence the right thing to do is to make these commit methods work
      on the unfiltered repository.
      
      In order to mutualize, we're actually making the
      `gitlab_revision_changeset` return also obsolete changesets if
      queried by exact hash. This is consistent with the Git case: a
      ref should never be obsolete, but an exact lookup can return
      unreferenced commits.
      
      In the tests, it was about time for the `make_empty_repo` helper
      to activate the evolve extension. Thankfully no other test is
      affected (without evolve, `amend` would strip the previous changeset)
      71abb991
    • Georges Racinet's avatar
      Commit: supporting pseudo-range notation (two dots) · 74f9767b
      Georges Racinet authored
      We will probably have to factorize this for reuse in
      FindCommits and the like. We'll see.
      74f9767b
    • Georges Racinet's avatar
      Commit: proper not_found in CommitIsAncestor · 0e78099a
      Georges Racinet authored
      This one was in the way of the current goal: getting the
      functional tests to pass.
      0e78099a
    • Georges Racinet's avatar
      Ref: proper not_found in FindBranch · d3f79d75
      Georges Racinet authored
      Again one on the path to get functional tests pass.
      d3f79d75
    • Georges Racinet's avatar
      Commit: proper not_found in CommitsBetween · cde272dc
      Georges Racinet authored
      This also brings the coverage up to 100% by actually testing
      the `not_found()` helper.
      cde272dc
    • Georges Racinet's avatar
      errors: helper for NOT_FOUND · d66a1b4c
      Georges Racinet authored
      As said in the docstring, we don't gain that much, especially
      with the caller probably needing a multi-line statement.
      
      Still it's a bit less painful to use, and good for uniformity.
      d66a1b4c
  11. Nov 15, 2020
  12. Nov 10, 2020
    • Georges Racinet's avatar
      f1a2babb
    • Georges Racinet's avatar
    • Georges Racinet's avatar
      Repository loading: returning proper error if not found · 66a4803f
      Georges Racinet authored
      We already had good enough error responses for the case when
      the *storage* is not found, but it was missing for the case
      when the repository is not found in an existing storage.
      
      This is important, because it can actually break the landing page
      of some users: the Rails application does not seem to expect an
      unspecified Gitaly error here, but it should recover from
      NOT_FOUND.
      
      I've been impaired by this on dev setup after
      with some repository removals, but don't have anything of that
      kind on hand any more, which would be more reassuring.
      
      We could have a better separation in concerns, as the
      subsequent change in `RepositoryExists()` indicates, but that's
      not a blocker for the imminent release.
      66a4803f
  13. Nov 09, 2020
  14. Oct 31, 2020
  15. Nov 01, 2020
Loading