Skip to content
Snippets Groups Projects
  1. Aug 25, 2020
  2. Aug 04, 2020
  3. Jul 31, 2020
  4. Jul 30, 2020
  5. Jul 27, 2020
    • Georges Racinet's avatar
      Merging heads on branch default · e0ebc7343459
      Georges Racinet authored
      Actually that second head was on mirror.octobus.net only
      (found by CI experiments for heptapod/heptapod which install
      this from mirror.o.n), but it's enough of a pain to merge it
      explicitely.
      
      Of course diff with `p1()` should be empty
      e0ebc7343459
  6. Jul 24, 2020
  7. Jul 16, 2020
  8. Jul 11, 2020
    • Georges Racinet's avatar
      GitLab pre-receive: pass new vcs='hg' parameter · 9a913324753c
      Georges Racinet authored
      Related to heptapod#295: this parameter will make it
      possible to differentiate between calls to the `/allowed` internal
      API endpoint for pre-receive checks (common among supported VCSes)
      and for Git client SSH operation.
      
      Since it'll make the pre-receive call use the `HgAccess` class
      instead of the previously used `GitAccess`, we need now also to
      pass the corresponding Mercurial wire protocol command name for
      pushes.
      9a913324753c
  9. Jul 08, 2020
  10. Jun 29, 2020
  11. Jun 28, 2020
    • Georges Racinet's avatar
      subrepos: forbid any pull of subrepos on the server side · 75d393740150
      Georges Racinet authored
      See heptapod#311
      
      Subrepos are not needed to update a file, or to perform a
      merge. In a later version, we could simply neutralize the
      pull, but then we'd have to make sure that the commit logic
      is consistent (that's why commits are forbidden separately,
      too).
      
      In current Heptapod, the use of updates is always within
      shares used for server side operations and mergeability
      assessment. This change will prevent
      projects using subrepos to trigger hundreds of pulls that will
      take too much time, and create resource problems (maybe
      banning risks even) for hazardeous success anyway.
      75d393740150
    • Georges Racinet's avatar
      subrepos: a hook to forbid server-side commits · 89aaf7286fe7
      Georges Racinet authored
      See heptapod#311 for rationale
      89aaf7286fe7
  12. Jun 29, 2020
    • Georges Racinet's avatar
      git for subrepos: more robust parsing of .hgsub · eec9087800f7
      Georges Racinet authored
      We'd still have a long way to go for proper subrepositories
      support in Heptapod. With this change, at least, we won't get
      errors because a `.hgsub` file has a `subpaths` section.
      
      More precisely, we're using the same config parser as Mercurial
      does for this file.
      eec9087800f7
  13. Jun 26, 2020
  14. Jun 24, 2020
  15. Jun 18, 2020
  16. Jun 17, 2020
    • Georges Racinet's avatar
      branch: branchmap to gitlab branch conversion utilities · 9b95ea74c395
      Georges Racinet authored
      The provided `branchmap_branch_from_gitlab_branch()` is not
      equivalent to the `GitHandler.git_branch_for_branchmap_branch()`
      method, whose purpose is also to gate invalid new content, and
      needs a `ui` object for user feedback.
      
      When we drop the hg-git conversion, we'll do such validations
      separately.
      9b95ea74c395
    • Georges Racinet's avatar
      heptapod.gitlab.branch, split out of hgext3rd.heptapod.git · 311cd85da3bc
      Georges Racinet authored
      The pure bytes-string manipulation functions will need to
      be cleanly reused from elsewhere, and notably in HGitaly.
      
      This is also an opportunity to normalize and explain the
      terminology.
      311cd85da3bc
    • Georges Racinet's avatar
      git: setting default branch from Mercurial side · 6686c1b1d714
      Georges Racinet authored
      With the new storage of the default GitLab branch in the Mercurial
      repository, we need to set it as soon as possible,
      in preparation for when that's the
      only thing GitLab will see (instead of the Git HEAD).
      
      We need to set it, even if we have to choose a topic or a bookmark
      for that, and therefore we're doing it also for the Git repository,
      in order for the information to be consistent.
      
      So instead of choosing a named branch only if a previous value randomly
      chosen by other GitLab component was a topic, we build two sets
      of candidates, and pick among non named branches only if there's
      no named branch.
      
      The only case where we don't set it is if there are only wild
      heads *and* the special config item to refuse to choose among them
      is in place (there would be a "non wild" head otherwise)
      6686c1b1d714
    • Georges Racinet's avatar
      Storing and retrieving the default GitLab branch name · bd087392abb5
      Georges Racinet authored
      This new data is used often by GitLab, sometimes in an
      indirect way, as a default, that's why it's about the first
      thing to implement for Mercurial to get native in Heptapod.
      bd087392abb5
Loading