Skip to content
Snippets Groups Projects
  1. Mar 30, 2020
  2. Mar 27, 2020
  3. Mar 16, 2020
  4. Mar 26, 2020
  5. Mar 25, 2020
  6. Mar 18, 2020
  7. Mar 17, 2020
  8. Mar 16, 2020
  9. Mar 15, 2020
  10. Mar 14, 2020
    • Georges Racinet's avatar
      Extensions: activating 'share' · 49f988c0934d
      Georges Racinet authored
      It will notably be useful for all cases where the server
      needs to use a working directory, so that concurrency can
      be supported.
      49f988c0934d
    • Georges Racinet's avatar
      using the new gitlab_mirror hook · 79bbbafd2ddb
      Georges Racinet authored
      From now on, Heptapod will write directly into GitLab's Git
      repository.
      79bbbafd2ddb
    • Georges Racinet's avatar
      Merged heptapod-0-8 for new hg-git system · a2a5a534b6ab
      Georges Racinet authored
      The new hg-git rewrapping (that works directly on GitLab's
      Git repository) is available yet not in use in the heptapod-0-8
      branch.
      
      We will activate it in the default branch, targetting GitLab 12
      a2a5a534b6ab
    • Georges Racinet's avatar
      git: postponing post-receive after transaction is closed · 384a4df225f5
      Georges Racinet authored
      As already indicated in the former Heptapod fork of hg-git,
      at this point the changes are already visible, but the locks aren't
      released. This is enough to be relevant to whatever GitLab needs to do,
      while preventing another push to change things before our post-receive
      is queued.
      
      Nowadays this latter protection is rather theoretical: GitLab treatment
      is highly asynchronous anyway.
      384a4df225f5
    • Georges Racinet's avatar
      git: clarity refactors · c1d8a5e3e0ff
      Georges Racinet authored
      Renamed `topic_new_hg_sha()` into `analyze_vanished_topic`,
      which underlines that it works on a topic that is no more
      visible.
      
      Split out `analyze_vanished_refs()` from `compare_exportable`,
      to make the general articulation more visible.
      
      Gave more explicit namings to many variables.
      c1d8a5e3e0ff
    • Georges Racinet's avatar
      git: split generate_prune_changes() from compare_exportable() · 91e5a7ad866d
      Georges Racinet authored
      This makes it easier to unit-test and we take the opportunity
      to catch `RepoLookupError` in detection of previously closed
      branches.
      91e5a7ad866d
    • Georges Racinet's avatar
      git: honouring prune-previously-closed-branches=no · 0f1a020b7c06
      Georges Racinet authored
      we could have dropped this setting, but it was simpler to just
      make it work
      0f1a020b7c06
  11. Mar 13, 2020
  12. Mar 12, 2020
    • Georges Racinet's avatar
      gitlab hooks: stop returning None for no changes · 506e8eeacf44
      Georges Racinet authored
      This is more robust.
      
      It was originally intended as a way for callers to check
      the condition, but it makes something to check systematically
      (exception in string concatenation downstream if forgotten)
      and it's better if callers check before hand (worst case they
      will emit empty lines in the likes of `ui.status` if forgotten)
      506e8eeacf44
  13. Mar 13, 2020
  14. Mar 12, 2020
    • Georges Racinet's avatar
      git: restoring protection against prune of the default branch · 16b10f95cd02
      Georges Racinet authored
      GitLab's pre-receive hook would refuse to prune it, voiding
      the whole transaction. It's better if we ignore it
      (been in the functional tests for a while, too)
      16b10f95cd02
    • Georges Racinet's avatar
      git: making mandatory GitLab hooks raise Abort · 5841c63f9dcb
      Georges Racinet authored
      Typically, that would be the pre-receive hook.
      The Heptapod fork of hg-git used to raise RuntimeError
      and catch it from the caller (here that would be
      `heptapod_apply_changes`)
      
      We're starting over a bit
      tighter, meaning that only those changes that would
      be accepted by GitLab can enter Mercurial.
      
      Since on the GitLab side, we have a rule that Mercurial can
      force on any branch, this is probably acceptable, avoiding
      locking the Maintainers away.
      5841c63f9dcb
    • Georges Racinet's avatar
      Git: branches are closed by default · fa0b6bf4b514
      Georges Racinet authored
      This was indeed the default value of this Heptapod specific option,
      no longer available on mainline hg-git
      fa0b6bf4b514
    • Georges Racinet's avatar
      git: special rules for topics not visible anymore · 94e0688e5ff8
      Georges Racinet authored
      These are reimported, much simplified and made more robust
      from the Heptapod fork of hg-git.
      
      This is the bulk of what has been done in spring and summer
      of 2019 to make merge detection work on Heptapod.
      
      The unfiltered repo is kept as a permanent attribute of the
      handler. While this probably has no impact on performance,
      it's cleaner this way, and will allow direct access from the tests.
      94e0688e5ff8
  15. Mar 11, 2020
  16. Mar 10, 2020
    • Georges Racinet's avatar
      git: GitLab notification logic · 0f4bdb3cd5e8
      Georges Racinet authored
      Each call to our specific `heptapod_apply_changes` is
      enclosed in a pre-receive/post-receive pair, as planned.
      
      We're adopting `gitlab_get_hook` from the Heptapod fork
      of hg-git.
      
      In the tests, we introduce the necessary monkey patching
      in order not to have errors due to GitLab not being there,
      with a recording system. Assertions on the fired notifications
      are minimal: just one is enough to display how to build on top
      of that.
      0f4bdb3cd5e8
Loading