- Dec 23, 2023
-
-
Georges Racinet authored
As often, it doesn't change in patch versions.
-
Georges Racinet authored
In Gitaly protocol 16.3, the `ignore_whitespace_changes` boolean disappears, being replaced with a 3-valued enum, corresponding to two levels of whitespace ignoring in Git. The disparition means that the attribute was long deprecated, and no upstream client had been using it for a while, so it was about time we implement the "new" `WhitespaceChanges` enum. Closes #137
-
- Dec 17, 2023
-
-
Georges Racinet authored
Closes #164 In the course of implementation, we introduce the new `changeset_by_commit_id` helpers which are useful in cases where the input is expected to be a full Node ID (instead of any Git revspec) and that is to be validated (because Gitaly does). Would need their separated testing to commit them separately, too lazy today for that.
-
- Dec 19, 2023
-
-
Georges Racinet authored
All these metadata reach our code as `str` instances, this one (previously not tried from the clients) was wrongly implemented as if the incoming data were `bytes`.
-
- Dec 17, 2023
-
-
Georges Racinet authored
Will spare us and readers some repetitions.
-
Georges Racinet authored
This allows us to remove much pollution in `test_compare_squash`.
-
- Dec 14, 2023
-
-
Georges Racinet authored
The breakthrough is that HGitaly is able to control internal Git mirroring and this can be tested from HGitaly (ordinary) integration tests. The presence of the `commit_author` and `timestamp` attributes raise some questions more explicitely than it was the case in the Rails app, where the feature has been implemented long ago by spawning a Mercurial subprocess. We decided to behave identically, and in particular to postpone the question of representing the difference between committer and author to another time, as such a distinction does not exist currently in Mercurial (could be an extension around providing that, though). The `UserSquash` method in itself was only chosen because it does not have many options and is at its core very simple to implement. Closes #163
-
Georges Racinet authored
The `HGitalyServicer` base class now provides a `for_mutation_by` optional argument that triggers the setting of all needed repository config items and environment variables as already in use when spawning Mercurial subprocesses from the Rails application: repository mode (nativity, with Git mirroring or not), link to MR to allow distinguishing between merge permissions and direct pushes, etc. The acting user is part of the request message in all examples we have considered so far, hence passed down by the caller (concrete service subclass). Other metadata are expected as invocation metadata (hence HTTP/2 headers, which matches what also happens between Workhorse and the Rails aplication). We had to add invocation metadata handling to the `FakeContext` to maintain coverage. The import path from `grpc` is probably instable, but we'll live with it. WIP implement UserSquash, with Git mirroring or not Needs lint to be ok, coverage to be 100%, a decision about itering on invocation metadata so much. The breakthrough is that HGitaly is able to control internal Git mirroring and this can be tested from HGitaly (ordinary) integration tests. At this point this does not implement passing of user information to internal API (can only be tested from functional tests, as it requires a fully working Heptapod instance). The `UserSquash` method in itself was only chosen because it does not have many options and is at its core very simple to implement. WIP to fold: refactoring putting mutation metadata in repo config/environ WIP first version working in functional tests WIP some linting (grpc import in tests will be used later) WIP added tests with Gitaly Almost complete (for_mr_iid missing) except coverage when skipping Gitaly Comparison accept_mr_iid Full coverage for UserSquash
-
Georges Racinet authored
Very similar to what, e.g., mercurial-testhelpers and many similar tools do. This is as close to the CLI as possible, and suitable for methods that can be implemented in a single mutating command, as the command will typically enclose the actual mutation in its own transaction. Methods to be implemented as a succession of mutation commands should better manage a single transaction themselves, probably at the price of a greate duplication from Mercurial core.
-
- Nov 30, 2023
-
-
Georges Racinet authored
We take `UserSquash` as an example as it will be the first implemented method (see #163) because of its calling simplicity.
-
- Dec 12, 2023
-
-
Georges Racinet authored
-
- Nov 24, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
There is a compatibility problem lower level than HGitaly with the current stable Mercurial (6.6). It looks at first sight to lie in Evolve, but it could be in mercurial-testhelpers. It should not prevent us going forward with HGitaly, at least on Mercurial 6.5
-
Georges Racinet authored
With 0.42 released as part of the stable branch (Heptapod 0.40), we will need to open up 0.43 for the default branch.
-
- Nov 21, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Nov 20, 2023
-
-
Georges Racinet authored
In case a project id is reused (Heptapod application context, since the repo path is derived from the project id) or a repository path is reused (e.g. in RSpec tests), it is possible that a previous failed cleanup (crash or brutal stop before the final trashed repo `rmtree) would get in the way of the removal. Unlikely, but easy to prevent by making the name in trash unique (time-based, random would also have been good).
-
Georges Racinet authored
It was a mistake to depend on `load_repo`, as it will fail if, e.g., the `.hg` sub directory does not exist (seen in Rails RSpec tests) and various corrupted cases that a *removal* should clean up. The price to pay is the transactionality of the roster, but we cannot lock it properly without a repo. In theory in should be possible to instantiate the `Vfs` separately, but it does not seem to matter so much. With this change, if removing the working directories fails, it will not prevent removing the trashed repository (but of course we risk a later collision in workdirs). Backs out in particular changeset 1c735d40cfe7
-
- Nov 18, 2023
-
-
Georges Racinet authored
-
- Nov 15, 2023
-
-
Georges Racinet authored
The error message is ``` *** failed to import extension "hgitaly": unicode '[OPTIONS]...' found in cmdtable.hgitaly-serve ``` It is completely obscure why this has not been a problem before. Got this with Mercurial 6.4.5, then 6.4 on Python 3.9 (usually running with Python 3.10 if that makes any difference).
-
- Nov 13, 2023
-
-
Georges Racinet authored
-
- Nov 18, 2023
-
-
Georges Racinet authored
Now that we need to load the repo for the working directories machinery, no need to repeat the exceptions that can be raised by the loading. The only difference lies in the error message on missing repository, which we are confortable ignoring.
-
Georges Racinet authored
This is obviously useful to avoid wasting disk space, but also prevents vicious errors when repository paths are reused, which happens mostly in RSpec tests such as `spec/lib/gitlab/mercurial/hgitaly_*_spec.rb`
-
- Nov 12, 2023
-
-
Georges Racinet authored
We chose to use the same detector as Gitaly's: go-enry/go-license-detector, so that we get the same results. Of course this means we have to provide it in CI and Omnibus builds. Closes #161
-
- Nov 16, 2023
-
-
Georges Racinet authored
It was already duplicated between `test_errors` and `test_linguist` and will be useful in other cases. We had to rename it a bit to make it more explicit out of the context of a given test module.
-
- Nov 14, 2023
-
-
Georges Racinet authored
-
- Nov 10, 2023
-
-
Georges Racinet authored
In the case of unknown storage, we find it useful to repeat the requested name, hence we simply stop comparing exactly the details. In the case of the missing repository field, the new upstream message is clearly better, so we adopt it.
-
Georges Racinet authored
The change appeared between Gitaly 16.0 and 16.2.
-
- Oct 14, 2023
-
-
Georges Racinet authored
See comment of parent changeset (merge stable)
-
Georges Racinet authored
This brings in the new `MercurialOperationsService`, together with its `hgitaly` ruby gem bump. Since we've already tagged 0.41.0, this means the next version should be 0.42.0, most probably with the jump to Gitaly protocol v16.1
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
hence we publish a Python package and a Ruby gem
-
- Oct 11, 2023
-
-
Georges Racinet authored
This new service will take care of all mutations, in analogy with Gitaly's `OperationsService`. The first method is actually an exception, since it does not perform any mutation, but it will make sense to have it beside `Merge` and `FastForwardMerge`. Normally, we should not add it in stable branches, but the default branch is currently tied to upstream protocol updates, hence to the release schedule of the Rails app, which is not released frequently due to jumps for upstream catch-up. It will be acceptable if clients use this only if certain feature flags that are `false` by default are activated. The `MergeAnalysis` method should provide everything needed by the Rails app for all merge operations (fast-forward or not). The conflicts detection is the second use case of working directories (after `CommitLanguages`), and the first introducing local modifications.
-
- Oct 13, 2023
-
-
Georges Racinet authored
It turns out that `WorkingDirectory.command()` was always running `update` (!). Clearly a refactoring leftover that went unnoticed because we did not have explicit purge testing. Now we do, with a focus on interrupted merges (with or without conflicts) as this is needed for #155
-
- Oct 09, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-