heptapod issueshttps://foss.heptapod.net/groups/heptapod/-/issues2024-03-21T13:36:35Zhttps://foss.heptapod.net/heptapod/hgitaly/-/issues/143DiffService: implement `MergeCommitDiffMode` options2024-03-21T13:36:35ZGeorges RacinetDiffService: implement `MergeCommitDiffMode` optionsIntroduced in Gitaly v15.11:
```diff
~/heptapod/gitaly $ git diff 28c0539251cf00a675b78e987ff30b7741425653..24badf7502c1864dc59e4f19bbebe53a1d36b638 -- proto/*.proto internal/backup
diff --git a/proto/diff.proto b/proto/diff.proto
inde...Introduced in Gitaly v15.11:
```diff
~/heptapod/gitaly $ git diff 28c0539251cf00a675b78e987ff30b7741425653..24badf7502c1864dc59e4f19bbebe53a1d36b638 -- proto/*.proto internal/backup
diff --git a/proto/diff.proto b/proto/diff.proto
index bda865fa9..5f6b4759d 100644
--- a/proto/diff.proto
+++ b/proto/diff.proto
@@ -265,6 +265,20 @@ message DiffStatsResponse {
// to its parent. Merge commits will show files which are different to all of
// its parents.
message FindChangedPathsRequest {
+ // MergeCommitDiffMode controls which mode to use to produce diff output for merge commits
+ enum MergeCommitDiffMode {
+ // MERGE_COMMIT_DIFF_MODE_UNSPECIFIED is the default value.
+ // It is equivalent to DIFF_MODE_INCLUDE_MERGES.
+ MERGE_COMMIT_DIFF_MODE_UNSPECIFIED = 0;
+ // MERGE_COMMIT_DIFF_MODE_INCLUDE_MERGES tells git to also show differences for merge commits.
+ // Please refer to the documentation of the `-m` flag of git-diff-tree(1).
+ MERGE_COMMIT_DIFF_MODE_INCLUDE_MERGES = 1;
+ // MERGE_COMMIT_DIFF_MODE_ALL_PARENTS tells git to only show differences for
+ // files which were modified from all parents.
+ // Please refer to the documentation of the `-c` flag of git-diff-tree(1).
+ MERGE_COMMIT_DIFF_MODE_ALL_PARENTS = 2;
+ }
+
// Request is a single request to pass to git diff-tree.
message Request {
// TreeRequest compares two trees.
@@ -305,11 +319,16 @@ message FindChangedPathsRequest {
repeated string commits = 2 [deprecated=true];
// requests specifies the requests of what to compare.
repeated Request requests = 3;
+
+ // MergeCommitDiffMode controls how merge commits are treated.
+ MergeCommitDiffMode merge_commit_diff_mode = 4;
}
// Returns a list of files that have been changed in the commits given
message FindChangedPathsResponse {
- // This comment is left unintentionally blank.
+ // paths contains the attributes for one changed file. In case of merge
+ // commits, or when comparing three or more commits, a file might be included
+ // more than once if it was changed between multiple commits.
repeated ChangedPaths paths = 1;
}
```
Of course how that translates to Mercurial is also to be defined.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/764VCS type alignment on home panel2024-03-21T13:27:26ZGeorges RacinetVCS type alignment on home panelWith the move to upstream GitLab v15.9, the short VCS type in project home page is now in exponent position.
![home-panel-v15.9](/uploads/c6bba4a6c1060f863041978ecc06fe2d/home-panel-v15.9.png)
This should just be a matter of using the ...With the move to upstream GitLab v15.9, the short VCS type in project home page is now in exponent position.
![home-panel-v15.9](/uploads/c6bba4a6c1060f863041978ecc06fe2d/home-panel-v15.9.png)
This should just be a matter of using the appropriate CSS class in app/views/projects/_home_panel.html.hamlHeptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/760Implement change of storage for Mercurial projects2024-03-21T13:42:51ZGeorges RacinetImplement change of storage for Mercurial projectsHeptapod still supports having only one Mercurial-enabled repository storage (i.e Gitaly and HGitaly services). However, it will be in the not-so-far future.
At this point, `Projects::UpdateRepositoryStorageService` will have to support...Heptapod still supports having only one Mercurial-enabled repository storage (i.e Gitaly and HGitaly services). However, it will be in the not-so-far future.
At this point, `Projects::UpdateRepositoryStorageService` will have to support Mercurial projects, its point being to move repositories from one storage to the other. The already are some provisions toward that, but it's obviously incomplete (see in particular how `Concerns::updateRepositoryStorageMethods` handles the Project repository).Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/758Capability to upgrade a GitLab instance to Heptapod2024-03-21T13:42:50ZGeorges RacinetCapability to upgrade a GitLab instance to HeptapodIt should be possible to upgrade a GitLab CE instance to Heptapod, and it certainly has been possible for many Heptapod versions in the past.
However, some of our data migrations were breaking rules that once were soft and have since be...It should be possible to upgrade a GitLab CE instance to Heptapod, and it certainly has been possible for many Heptapod versions in the past.
However, some of our data migrations were breaking rules that once were soft and have since become mandatory. It was reasonable because many of these rules are geared towards high volumetry (as can be found on gitlab.com) which was not a concern to us at the time yet have become enforced upstream.
The typical case would be `AddHgAsDefaultVcs` as it was until the merge of GitLab 15.8: it changes the schema (default value on `application_settings`) and updates a column on the `namespaces` table: it wouldn't have passed upstream review at the time, but there is a strict enforcement nowadays that migrations have to use either Data Definition Language (DDL) or Data Manipulation Language (DML). It makes the migration fail if running anew on recent Heptapod versions (which won't happen unless upgrading from an upstream GitLab instance because it dates way back). Also it breaks all the RSpec test that contain *any* migration test.
The problem in RSpec tests will of course be solved with the [merge of GitLab 15.8](!491), yet in a minimal way that is not suitable to upgrade an upstream GitLab CE instance.
This issue to keep track of the work need for such upgrades to be supported:
- [ ] `application_settings.vcs_types` should be introduced by a single migration, with the correct default set in the schema (single row table)
- [ ] `namespaces.default_vcs_type` does not need a migration of the value if starting afresh on current Heptapod versions. A `NULL` value means to default to Application Settings, so we don't need any backfill.
- [ ] actual testing of an upgrade from GitLab (how to automate that?)Heptapod 1.4https://foss.heptapod.net/heptapod/hgitaly/-/issues/125Support other storages than `default`2023-03-28T19:00:27ZGeorges RacinetSupport other storages than `default`Currently, HGitaly servers only accept repositories with `storage_name=default`.
Actual sharding in HGitaly is not on the table yet, and serving several storages with a single HGitaly server even less, but we might soon want to have sev...Currently, HGitaly servers only accept repositories with `storage_name=default`.
Actual sharding in HGitaly is not on the table yet, and serving several storages with a single HGitaly server even less, but we might soon want to have several storages in a Heptapod installation, with a single one for Mercurial repositories.
In any case, even with a single storage per HGitaly server, it would have to match the name as known in the Rails application, hence potentially not 'default'.
It would be good enough for the foreseeable future to configure both the repositories root and the storage name. We don't need a lookup in a full mapping.HGitaly3: fully in chargehttps://foss.heptapod.net/heptapod/hgitaly/-/issues/123Structured logs2024-03-21T13:42:02ZGeorges RacinetStructured logsSo-called "structured logs" are simply logs where each line is a JSON document.
This is the de-facto standard followed by many projects, notably most GitLab components (some also have legacy logs, which are deprecated). Providing struct...So-called "structured logs" are simply logs where each line is a JSON document.
This is the de-facto standard followed by many projects, notably most GitLab components (some also have legacy logs, which are deprecated). Providing structured logs would presumably allow to leverage the same log mining tools as GitLab generally supports.
It is not clear whether we should systematically switch to structured logs, using the `logging` Python module or simply use them in the general requests logger.
In any case, the recent logging of [correlation_id](#122) has shown the limits of the current approach, with `logging` format strings making all their keys required (even replacing `correlation_id` with an empty string when not available would not be very satisfying), whereas a JSON logger would probably be more flexible.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/719Display HGitaly version in admin dashboard2024-03-21T13:27:24ZGeorges RacinetDisplay HGitaly version in admin dashboardSometimes, we deploy HGitaly on foss.h.n in advance of the full release. It could be done for other instances as well. Also longer term, with %"HGitaly3: fully in charge", it will be possible to have remote HGitaly servers.
There is a n...Sometimes, we deploy HGitaly on foss.h.n in advance of the full release. It could be done for other instances as well. Also longer term, with %"HGitaly3: fully in charge", it will be possible to have remote HGitaly servers.
There is a nice sub-panel for Gitaly servers, we should have the same for HGitaly.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/714Default branch value overridden by topic2024-03-21T13:27:26ZGeorges RacinetDefault branch value overridden by topicIt happened today here on mercurial/mercurial-devel>: `topic/stable/uninstall-issue6762` became the default branch.
From the logs, it's not clear why, except that it was made through HGitaly:
```
[2022-11-28 12:15:00,917] [501] [DEBUG]...It happened today here on mercurial/mercurial-devel>: `topic/stable/uninstall-issue6762` became the default branch.
From the logs, it's not clear why, except that it was made through HGitaly:
```
[2022-11-28 12:15:00,917] [501] [DEBUG] [hgitaly.interceptors] Starting to process RPC CountCommitsRequest { repository { storage_name: "default" relative_path: "@hashed/78/5f/785f3ec7eb32f30b90cd0fcf3657d388b5ff4297f2f9716ff66e9b69c05ddd09.git" gl_repository: "project-22" gl_project_path: "mercurial/mercurial-devel" } revision: "topic/stable/uninstall-issue-6762" }
[2022-11-28 12:15:03,045] [501] [DEBUG] [hgitaly.interceptors] Starting to process RPC FindAllBranchNamesRequest { repository { storage_name: "default" relative_path: "@hashed/78/5f/785f3ec7eb32f30b90cd0fcf3657d388b5ff4297f2f9716ff66e9b69c05ddd09.git" gl_repository: "project-22" gl_project_path: "mercurial/mercurial-devel" } }
[2022-11-28 12:15:03,245] [501] [DEBUG] [hgitaly.interceptors] Starting to process RPC WriteRefRequest { repository { storage_name: "default" relative_path: "@hashed/78/5f/785f3ec7eb32f30b90cd0fcf3657d388b5ff4297f2f9716ff66e9b69c05ddd09.git" gl_repository: "project-22" gl_project_path: "mercurial/mercurial-devel" } ref: "HEAD" revision: "refs/heads/topic/stable/uninstall-issue-6762" }
```
The above extract is all requests for the project, from the first involving the topic up to the one setting default branch, it case it helps understanding the sequence.
We should at least add logs in the Mercurial-specific code in `PostReceiveWorker` that is supposed to set the default branch if needed.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/706Forking a Git repository if personal quota is 02024-03-21T13:42:50ZGeorges RacinetForking a Git repository if personal quota is 0On foss.heptapod.net and heptapod.host, most users don't have the rights to create projects in their personal namespaces. In the former, that is because we want to control what people upload on a very public instance. In the latter, beca...On foss.heptapod.net and heptapod.host, most users don't have the rights to create projects in their personal namespaces. In the former, that is because we want to control what people upload on a very public instance. In the latter, because invoicing is tied to top-level (actual) groups.
But the Git fork page still proposes the personal namespace to host the fork. Similarly to what has already been done with creation / import pages, we must exclude it, and perhaps even add a message urging users to make personal subgroups of their top-level / company groups.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/705Runner does not find obsolet changeset2024-03-22T08:58:00ZCédric Kriercedric.krier@b2ck.comRunner does not find obsolet changeset<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Regression" or "Bug" label:
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Regression
- https://...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Regression" or "Bug" label:
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Regression
- https://foss.heptapod.net/heptapod/heptapod/issues?label_name%5B%5D=Bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
When pipeline as started but the changeset has been amended, jobs that has not yet pull the repository fails.
### Steps to reproduce
Make a changeset that trigger a pipeline
Amend and push this changeset before the jobs of the pipeline are finished
### Example Project
https://foss.heptapod.net/tryton/tryton-mono-test/-/pipelines/58435/failures
### What is the current *bug* behavior?
The jobs fails due to external condition.
### What is the expected *correct* behavior?
I would expect that the jobs pull the obsolete changeset and keep running.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/703Migration to native, failed Notes on Heptapod Rails2024-03-21T13:27:26ZGeorges RacinetMigration to native, failed Notes on Heptapod RailsThe migration of this very project to native Mercurial produced a couple of errors in Notes:
```
there are errors for {:notes=>[143179, 142308, 142256, 142301, 142303, 142305, 142310]}. Please check application log for details
```
The ...The migration of this very project to native Mercurial produced a couple of errors in Notes:
```
there are errors for {:notes=>[143179, 142308, 142256, 142301, 142303, 142305, 142310]}. Please check application log for details
```
The error logs are the same for all these 7 Notes:
```json
{
"severity": "ERROR",
"time": "2022-10-01T11:44:09.615Z",
"correlation_id": null,
"message": "Failed to migrate Note id=143179",
"backtrace": [
"lib/gitlab/timeless.rb:11:in `timeless'",
"lib/heptapod/native_mercurial/migrator.rb:40:in `timeless_save'",
"lib/heptapod/native_mercurial/migrator.rb:253:in `save_note_if_changed'",
"lib/heptapod/native_mercurial/migrator.rb:262:in `block in migrate_notes'",
"lib/heptapod/native_mercurial/migrator.rb:259:in `migrate_notes'",
"lib/heptapod/native_mercurial/migrator.rb:189:in `do_migrate'",
"lib/heptapod/native_mercurial/migrator.rb:135:in `block in migrate!'",
"lib/heptapod/native_mercurial/migrator.rb:124:in `block (4 levels) in enter'",
"lib/heptapod/native_mercurial/migrator.rb:107:in `with_record'",
"lib/heptapod/native_mercurial/migrator.rb:123:in `block (3 levels) in enter'",
"lib/heptapod/native_mercurial/migrator.rb:50:in `vcs_type_enforcer'",
"lib/heptapod/native_mercurial/migrator.rb:122:in `block (2 levels) in enter'",
"lib/heptapod/native_mercurial/migrator.rb:61:in `with_project_readonly'",
"lib/heptapod/native_mercurial/migrator.rb:121:in `block in enter'",
"lib/heptapod/native_mercurial/migrator.rb:87:in `try_obtain_exclusive_lease'",
"lib/heptapod/native_mercurial/migrator.rb:120:in `enter'",
"lib/heptapod/native_mercurial/migrator.rb:133:in `migrate!'",
"lib/tasks/migrate/migrate_to_native_hg.rake:37:in `block (3 levels) in <top (required)>'"
],
"project_id": 5,
"project_full_path": "heptapod/heptapod"
}
```
Given this backtrace, it's possible that a simple retry would fix them (will attempt that later)Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/702(Legacy Mercurial) problem reopening old branches2024-03-21T13:42:50ZGeorges Racinet(Legacy Mercurial) problem reopening old branchesIn case a named branch has been closed long ago, it is possible that GitLab holds no references to what its head was before the closing changeset. In that case, pushing a new child of the former head can fail during the conversion to the...In case a named branch has been closed long ago, it is possible that GitLab holds no references to what its head was before the closing changeset. In that case, pushing a new child of the former head can fail during the conversion to the internal Git repository with a bad Git object message.
This happened to me with the `heptapod-0-23` branch of this very project: the former head was da810f85b7e1 and had exactly one child, the closing changeset f89d0daa76b0. The fact that da810f85b7e1 is a tagging changeset does not imply that it has itself a GitLab reference).
The root cause is likely that the Git commit converted from this former head has been garbage collected. A solution could be to add closing changesets (and tagging changesets) to the "keep around" special references, but it's dubious that it would be worth the effort, and that wouldn't restore the missing Git commits (they would need to be reexported, which is a bit painful).
At this point in the development of Heptapod, the simplest solution is to migrate the project to native Mercurial, which I just did for heptapod/heptapod>. Afterwards, I was able to push the reopening (with the `--force` modifier because of the client-side protection against multiple heads). This confirms that native projects are not affected.
The migration to native is still deemed to be experimental, though. Hopefully, it will become more mainstream soon.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/691Review logos and branding2024-03-21T13:42:50ZGeorges RacinetReview logos and brandingIn upstream GitLab 15.0, there is a change of logos and the way they are used in various pages, emails. There is notably a possibility to add variable text in some of the logos.
The resulting conflicting merge will necessarily need furt...In upstream GitLab 15.0, there is a change of logos and the way they are used in various pages, emails. There is notably a possibility to add variable text in some of the logos.
The resulting conflicting merge will necessarily need further fixes, assessment will better be done in a production-style installation, hence when we make some pre-0.33 Docker images.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/690Consider upstream GitLab registry statistics2024-03-21T13:42:51ZGeorges RacinetConsider upstream GitLab registry statisticsIn version 15.0, a new projects (and root namespaces?) statistics field `container_registry_size` appears, hence duplicating our own `container_registry_size_share`.
We should consider whether it is appropriate to simply drop ours. Thi...In version 15.0, a new projects (and root namespaces?) statistics field `container_registry_size` appears, hence duplicating our own `container_registry_size_share`.
We should consider whether it is appropriate to simply drop ours. This isn't a trivial question, as the deduplicating of layers might be vastly different.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/681Branch removal by obsmarkers2024-03-21T13:27:25ZGeorges RacinetBranch removal by obsmarkersIn case a whole named branch is removed by changeset obsolescence, the corresponding GitLab branch is not removed.
As a result, the branch is lingering in the interface, and the Gitlab state file within the Mercurial repository has an en...In case a whole named branch is removed by changeset obsolescence, the corresponding GitLab branch is not removed.
As a result, the branch is lingering in the interface, and the Gitlab state file within the Mercurial repository has an entry for an obsolete changeset, which should not happen.
An example occured on this very project:
- I started the Heptapod 0.24 release branch as `heptapod-0.24` (that's a typo)
- Later on, I realised the error and rebased the changeset, with the new, correct `heptapod-0-24` branch name.
Expected behaviour: the GitLab branch should have been removed, same as if the branch was closed with `hg commit --close-branch`
This has bad consequences, see hgitaly#102Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/672Timeout error while rendering a commit diff2024-03-21T13:27:24ZGeorges RacinetTimeout error while rendering a commit diffSeveral occurrences on this instance of errors while highlightneing MR commit diffs:
```
Exception:
class: Timeout::Error
message: execution expired
backtrace:
lib/rouge/formatters/html_gitlab.rb:26:in `block (2 levels) in s...Several occurrences on this instance of errors while highlightneing MR commit diffs:
```
Exception:
class: Timeout::Error
message: execution expired
backtrace:
lib/rouge/formatters/html_gitlab.rb:26:in `block (2 levels) in stream'
lib/rouge/formatters/html_gitlab.rb:25:in `each'
lib/rouge/formatters/html_gitlab.rb:25:in `block in stream'
lib/rouge/formatters/html_gitlab.rb:19:in `stream'
lib/gitlab/highlight.rb:75:in `block in highlight_rich'
lib/gitlab/highlight.rb:75:in `highlight_rich'
lib/gitlab/highlight.rb:64:in `highlight_text'
lib/gitlab/highlight.rb:31:in `highlight'
lib/gitlab/highlight.rb:10:in `highlight'
app/presenters/blob_presenter.rb:15:in `highlight'
lib/gitlab/diff/highlight.rb:156:in `highlighted_blob_lines'
lib/gitlab/diff/highlight.rb:148:in `new_lines'
lib/gitlab/diff/highlight.rb:124:in `blob_highlighting'
lib/gitlab/diff/highlight.rb:89:in `highlight_line'
lib/gitlab/diff/highlight.rb:60:in `apply_syntax_highlight'
lib/gitlab/diff/highlight.rb:34:in `block in highlight'
lib/gitlab/diff/highlight.rb:29:in `map'
lib/gitlab/diff/highlight.rb:29:in `with_index'
lib/gitlab/diff/highlight.rb:29:in `highlight'
lib/gitlab/diff/file.rb:238:in `highlighted_diff_lines'
lib/gitlab/diff/parallel_diff.rb:17:in `parallelize'
lib/gitlab/diff/file.rb:243:in `parallel_diff_lines'
app/views/projects/diffs/_parallel_view.html.haml:5
app/views/projects/diffs/viewers/_text.html.haml:6
app/views/projects/diffs/_viewer.html.haml:14
app/views/projects/diffs/_content.html.haml:11
app/views/projects/diffs/_file.html.haml:42
app/views/projects/diffs/_diffs.html.haml:39
app/views/projects/commit/show.html.haml:15
```
I thought for a while it was due to memory pressure created by HGitaly, but it also happened while its footprint was small.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/670Changing source/target branch breaks the merge button2022-10-18T08:53:31ZRaphaël GomèsChanging source/target branch breaks the merge button### Summary
Sometimes a user decides to rebase their changes to a different Mercurial branch (in mercurial-devel, a switch from `default` to `stable` is common when we figure out it's a bugfix for a stable release) the source branch cha...### Summary
Sometimes a user decides to rebase their changes to a different Mercurial branch (in mercurial-devel, a switch from `default` to `stable` is common when we figure out it's a bugfix for a stable release) the source branch changes, which closes the MR. The user (or anyone with permissions) can choose to change the target branch from the Web UI to revive the MR. This causes a stuck `Checking pipeline status` + greyed-out merge button with `Merge blocked: all merge request dependencies must be merged or closed.` even though the new pipeline had succeeded on push.
@gracinet tells me this is load-dependent and not 100% reproducible.
### What is the current *bug* behavior?
Pipeline status never finishes loading, merge button is greyed out wrongly warning about unmet dependencies.
### What is the expected *correct* behavior?
New pipeline (with correct source and target branches) is attached to the MR and the merge button is usable like normal.
#### Details about the Heptapod instance where the bug occurs
foss.heptapod.net with:
Heptapod 0.30.2 (GitLab CE 14.8.6)
Mercurial 6.1.1 / Python 3.9.12 / hg-evolve 10.5.1Heptapod 0.31.2https://foss.heptapod.net/heptapod/heptapod/-/issues/669Snippets default branch discrepancy2024-03-21T13:27:25ZGeorges RacinetSnippets default branch discrepancySeen in [Docker-based functional tests for Heptapod 0.31.0rc1](https://foss.heptapod.net/heptapod/heptapod-tests/-/jobs/552344) and reproduced outside of CI, in Docker context only.
In Heptapod, Snippet repositories should behave exactl...Seen in [Docker-based functional tests for Heptapod 0.31.0rc1](https://foss.heptapod.net/heptapod/heptapod-tests/-/jobs/552344) and reproduced outside of CI, in Docker context only.
In Heptapod, Snippet repositories should behave exactly as in upstream GitLab. In particular, they are Git repositories.
The problem encountered is that their default GitLab branch (target of the `HEAD` symbolic reference) is `main` but the actual branch with content is `branch/default`. Preferred fix should be not to interfere with GitLab and use whatever it considers the default default branch to be.
Could simply be that we have a hardcoded check on `master`.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/667Incremental backups2024-03-21T13:42:49ZGeorges RacinetIncremental backupsAs a follow-up to heptapod#534, we don't lack much to support incremental backups (mostly `CreateBundleFromRefList` in HGitaly understanding the negative refs that `gitaly-backup` will send it).As a follow-up to heptapod#534, we don't lack much to support incremental backups (mostly `CreateBundleFromRefList` in HGitaly understanding the negative refs that `gitaly-backup` will send it).Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/661Tags cache cleanup for Mercurial 6.1.12024-03-21T13:27:23ZGeorges RacinetTags cache cleanup for Mercurial 6.1.1Mercurial 6.1.1 will automatically be included with next release.
It contains a fix for a [bug with tags after merges](https://bz.mercurial-scm.org/show_bug.cgi?id=6673) that needs server-side cleaning (also to stop propagation to client...Mercurial 6.1.1 will automatically be included with next release.
It contains a fix for a [bug with tags after merges](https://bz.mercurial-scm.org/show_bug.cgi?id=6673) that needs server-side cleaning (also to stop propagation to clients).
We'll need a background migration that amounts to this:
```
rm .hg/cache/*tag*
hg debugupdatecache
```
Problem underlined by the merge of Heptapod Shell in the course of heptapod#658, and *not* fixed by updating Mercurial on the client side.Heptapod 1.3.2