- Feb 26, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
This should help understanding heptapod#1365, which is reproduced only by the call from Rails to HGitaly on the production server (direct Mercurial CLI or from a Python intercepter on the production server works, HGitaly call on a dev machine also works). Thankfully, that was already covered.
-
- Feb 13, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
With the bump to Gitaly 16.7 and the implementation of `GetPatchID`, it is well worth a minor version bump
-
Georges Racinet authored
-
Georges Racinet authored
We were tempted for a while not to implement it, as almost everything it does can be done by `ListRefs`, but there were enough subtle differences (and the prefix matching) than finally it should be the simplest. Of course, heavy factorization occurred
-
Georges Racinet authored
It contains an important fix for `ChangelogRevisionData.files`. We don't seem to use that method yet, but are prone to, as it would be the main backing data access for the likes of `LastCommitForPath`
-
- Feb 12, 2024
-
-
Georges Racinet authored
Main motivation was external executables, but being comprehensive is expected.
-
Georges Racinet authored
Primary motivation was to list external executables, but it got bigger.
-
Georges Racinet authored
This induced better grouping of the existing sections, and hence higher heading levels for almost all existing ones.
-
- Feb 06, 2024
-
-
Georges Racinet authored
Since `git patch-id` does not involve the repository at all (it ingests a patch and outputs a hash), we are actually spawning it, with a Mercurial generated patch. For general consistency (and hoping it does not matter so much), we are computing the index lines as for the `RawDiff` method, but Git seems to actually ignore it. We are avoiding to extract the full content of binary files, as it would be expensive and essentially useless. This is also what Gitaly does, and we probably should generalize it to some other `DiffService` methods (to be checked) As the Comparison Tests display, the patch id computed by HGitaly turns out to be identical to the done by Gitaly for simple text-only diffs. That will obviously not be true of binary diffs.
-
- Feb 11, 2024
-
-
Georges Racinet authored
Was previously duplicated in `hgitaly.diff`
-
Georges Racinet authored
It is now able to understand diff headers generated without the option that dumps the full binary content in Git format, and returns whether a binary placeholder is to be generated.
-
Georges Racinet authored
The main purpose is to encapsulate the various accesses to file contexts, hence - improving clarity - making sure to avoid repeated manifest lookups (even though they are partially cached, because the C `lazymanifest` should be instantiated only once). We take the opportunity to change some old/new namings in favour of from/to, clearer to us and more in line with Gitaly protocol namings. The minor drawback is that some methods do not really need the change contexts.
-
Georges Racinet authored
Although all callers are expected to be in the `DiffService`, this will improve the testing capability. Large refactorings are obiously needed.
-
- Feb 10, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Feb 09, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 29, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 28, 2024
-
-
Georges Racinet authored
This is the counterpart of Gitaly's `OperationService.UserMergeBranch`. We had to make a dedicated method because - the two-phase system of Gitaly does not make sense for Mercurial: merging does move branches right away, as branch information is enclosed in the changeset. We started development by mimicking it, but it soon became overly complicated - we have the `semi_linear` field, nothing alike on the Gitaly side, since the method always performs a merge, and ours would fast-forward by default. - we have error cases that do not exist in Git (obsolescence and instability checks). Actually, we reuse some of Gitaly errors to ease the burden of treatment on the client side. The case of `reference_check` being a borderline, but it shouldn't matter much. (bumping minimal py-heptapod version for `GitRepo.git()` helper method)
-
- Jan 29, 2024
-
-
Georges Racinet authored
It will be more direct than doing the path conversion dance in actual test code.
-
Georges Racinet authored
In Comparison tests, this brings in particular the ability to normalize to Git (with a handler supplied by the actual test), as Gitaly has structured errors holding commit hashes. A prime example of this is `MergeConflictError`.
-
Georges Racinet authored
The `FindTag` method has long been returning structured errors.
-
Georges Racinet authored
Was interrupted mid-sentence.
-
- Jan 28, 2024
-
-
Georges Racinet authored
Because of the wrong type, this assertion was asserting nothing
-
Georges Racinet authored
They will be useful in more tests
-
Georges Racinet authored
It was all too easy to forget about it, since it is not directly tested by HGitaly itself.
-
Georges Racinet authored
Gitaly actually uses `PERMISSION_DENIED` when not allowed in pre-receive hook, which should not come as a surprise to people knowing its existence. In tests, we avoid using "permission denied" as a message to be clear that the resulting message in trailing metadata is not some placeholder.
-
- Jan 23, 2024
-
-
Georges Racinet authored
As explained in the docstring, this will allow comparing exceptions obtained with different gRPC methods. First use-case will be Mercurial version of `UserMergeBranch` that will have to differ yet will return same exceptions and structured errors. Also introducing a way normalize structured errors: some of them, such as `MergeConflictError` can indeed contain commit ids.
-
Georges Racinet authored
Because of the duality bewteen `OperationService` and `MercurialOperationService`, it will be useful to have it upstairs in the class hierarchy (attributes are really used, to that moving to an utility module will not be appropriate)
-
- Jan 18, 2024
-
-
Georges Racinet authored
It is meant to back `hg_reset_tags_cache`, but we make room for other caches that could be useful in the future.
-
Georges Racinet authored
-
Georges Racinet authored
The request and response for `Recover` were already defined, but the method was not.
-
Georges Racinet authored
No need for user and internal API dance, so that is simple. We assume that the list of Gitlab branches will be small enough, but we could make a streaming variant later on if needed. Similarly, upstream's `FetchRemote` is not streaming either.
-
Georges Racinet authored
The pre- and post-receive hooks error treatment is an important aspect of the question, since we cannot really test it from the service tests (we should at some point start a fake internal API server to that effect). However, the uniformity introduced by the `errors.operation_error_treatment` context manager makes it acceptable for the time being. First, it is entirely unit-tested, preventing stupid mistakes common in untested error treatment and second, this mutualization has the effect of having each gRPC method test its siblings, e.g., testing a real-life authorization failure would test all of them. It still depends on absence of typos in the protocol (would be better to make the `gitlab_hook` attribute name used in all of our methods). Since this method will soon be used on the Rails side for the file operations only, we don't add all checks that are in `UserFFBranch` for obsolete and unstable changesets, but we could.
-