- Feb 28, 2024
-
-
Georges Racinet authored
Sadly HGitaly will not see any boost except in bandwidth. Closes #165
-
Georges Racinet authored
-
- Feb 27, 2024
-
-
Georges Racinet authored
-
- Feb 26, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
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 14, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
This is nicer when running `rhgitaly --help`
-
Georges Racinet authored
Turns out this is a clap builtin. Closes #180
-
- 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
-