- Aug 25, 2020
-
-
Georges Racinet authored
For the record, dulwich 0.20 dropped Python 2 support.
-
Georges Racinet authored
We need a marker right now so that the requirements file shipping with the Rails application can refer to it.
-
- Aug 04, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jul 31, 2020
-
-
Georges Racinet authored
Besides, it can create conflicts with the version already listed in install requirements.
-
Antoine cezar authored
The original message was lacking usefull information to users not aware of Heptapod specific topics rules.
-
- Jul 30, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jul 27, 2020
-
-
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
-
- Jul 24, 2020
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Jul 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jul 11, 2020
-
-
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.
-
- Jul 08, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 29, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 28, 2020
-
-
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
-
- Jun 29, 2020
-
-
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.
-
- Jun 26, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 24, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jun 18, 2020
-
-
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.
-
- Jun 17, 2020
-
-
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.
-