- 16 Jul, 2020 1 commit
-
-
Georges Racinet authored
-
- 11 Jul, 2020 1 commit
-
-
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.
-
- 08 Jul, 2020 3 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- 29 Jun, 2020 4 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- 28 Jun, 2020 2 commits
-
-
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.
-
Georges Racinet authored
See heptapod#311 for rationale
-
- 29 Jun, 2020 1 commit
-
-
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.
-
- 26 Jun, 2020 2 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- 24 Jun, 2020 4 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- 18 Jun, 2020 3 commits
-
-
Georges Racinet authored
Will be useful for convention reuse from HGitaly
-
Georges Racinet authored
The namings are overall heavy (necessary to lift ambiguities due to so many meanings for "branch"), but it should perhaps have been called "parse_gitlab_branch_named_topic" or something.
-
Georges Racinet authored
Until now, we only had constants for the "ref" forms.
-
- 17 Jun, 2020 8 commits
-
-
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.
-
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.
-
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)
-
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.
-
Georges Racinet authored
This new option was available on the HGitaly side, so we'll need to provide it from here.
-
Georges Racinet authored
This had been done long ago on the HGitaly side, which had actually until recently the only Python 3 version of those test helpers. We're keeping the slightly awkward `return_ctx` though, just changing its default value. The `parent` parameter now accepts both `changectx` instances and binary node ids, so that we don't have to update all the tests that make use of it. Finally, we keep the coverage at 100%, even if launching only the tests of the test helpers.
-
Georges Racinet authored
with recent (and future) changes in the base images, with pytest for Python3 not necessarily having the '3' in its executable name, this felt necessary: otherwise we'd keep wondering all the time.
-
Georges Racinet authored
-
- 16 Jun, 2020 1 commit
-
-
Georges Racinet authored
That gives us in particular the new post-receive system for prunes.
-
- 15 Jun, 2020 3 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod-0-13
-
Georges Racinet authored
--HG-- branch : heptapod-0-13
-
Georges Racinet authored
--HG-- branch : heptapod-0-13
-
- 14 Jun, 2020 1 commit
-
-
Georges Racinet authored
--HG-- branch : heptapod-0-13
-
- 13 Jun, 2020 1 commit
-
-
Georges Racinet authored
Closes heptapod#292 File "mercurial/bundlerepo.py", line 481, in makebundlerepository url = b'bundle:%s+%s' % (util.expandpath(repopath), bundlepath) TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'str' Not detected by test because `makebundlerepository()` is called only for non-local repositories. --HG-- branch : heptapod-0-13
-
- 10 Jun, 2020 4 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod-0-13
-
Georges Racinet authored
--HG-- branch : heptapod-0-13
-
Georges Racinet authored
--HG-- branch : heptapod-0-13
-
Georges Racinet authored
Closes #3 --HG-- branch : heptapod-0-13
-
- 09 Jun, 2020 1 commit
-
-
Georges Racinet authored
This will make it possible to perform Merge Request detection for branches that are closed in the same push: heptapod#207 We're pruning the GitLab branch right away, which doesn't imped Gitaly from accessing the Git commits for all the changesets involved. To be fair, that's a race with the Git garbage collector, but it's very unlikely we'd have a problem with that on existing instances before we drop Git conversion anyway (Heptapod 0.14) --HG-- branch : heptapod-0-13
-