heptapod issueshttps://foss.heptapod.net/groups/heptapod/-/issues2024-03-21T13:36:35Zhttps://foss.heptapod.net/heptapod/hgitaly/-/issues/59CommitService: new word diff option2024-03-21T13:36:35ZGeorges RacinetCommitService: new word diff optionWith the update to Gitaly protocol 13.11.1 comes a new option to generate word-based diffs:
```
message CommitDiffRequest {
+ enum DiffMode {
+ // DEFAULT is the standard diff mode and results in a linewise diff for textfiles.
+ ...With the update to Gitaly protocol 13.11.1 comes a new option to generate word-based diffs:
```
message CommitDiffRequest {
+ enum DiffMode {
+ // DEFAULT is the standard diff mode and results in a linewise diff for textfiles.
+ DEFAULT = 0;
+ // WORDDIFF is a word diff and computes the diff for whitespace separated words instead of for whole lines.
+ WORDDIFF = 1;
+ }
+
Repository repository = 1 [(target_repository)=true];
string left_commit_id = 2;
string right_commit_id = 3;
@@ -65,6 +72,9 @@
int32 safe_max_files = 11;
int32 safe_max_lines = 12;
int32 safe_max_bytes = 13;
+
+ // DiffMode is the mode used for generating the diff. Please refer to the enum declaration for supported modes.
+ DiffMode diff_mode = 15;
}
```
### Task list
- [x] investigate how soon we need to implement it. In particular is it behind feature flags on the Rails side?
- [x] implementation design: do we have upstream Mercurial options for this, or perhaps some well-maintained extension or should we add a post-treatment of differing lines?
- [ ] implementationHeptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/465Native projects and GitLab branches and tags escaping2024-03-21T13:27:24ZGeorges RacinetNative projects and GitLab branches and tags escapingThe escaping we currently have for GitLab branches and tags will be a source of trouble with the transitional state of native projects:
- if we stop doing it, we can't convert to Git any more, which is obviously the ultimate end goal bu...The escaping we currently have for GitLab branches and tags will be a source of trouble with the transitional state of native projects:
- if we stop doing it, we can't convert to Git any more, which is obviously the ultimate end goal but wrecks all the intermediate steps we want to go through to reach it.
- if we keep on doing it, we will be creating unresolvable references. Actually, we already are with current (HGitaly1) native projects.
Solutions to this will need to take #451 into account, either as a further complication (e.g, we can't just change the escaping to make it bijective) or as a way to accept the imperfection. See #464 for the kind of consequences that can arise if it's slightly wrong.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/454Server-side amends for MR link2024-03-21T13:42:50ZGeorges RacinetServer-side amends for MR linkIn the Git world, one of the advantages of explicit merge commits upon MR acceptance is to play the role of the cover letter that some email-based workflow use: namely, a summary of what the entire series of changesets does.
I've been r...In the Git world, one of the advantages of explicit merge commits upon MR acceptance is to play the role of the cover letter that some email-based workflow use: namely, a summary of what the entire series of changesets does.
I've been reluctant to use the semi-linear merge method because it is heavy handed for MRs that consist of exactly one commit. But the MR can have interesting discussions. In some cases, most of the motivation behind the changes is actually in the MR description and comments.
So here's an idea: for MR with a single changeset and semi-linear method, the server could amend the unique changeset to add the MR link. Maybe we could do that as well in other cases (squash come to mind, but it's already almost there, with the message of the resulting commit being under user control).Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/450Removing a tag from the UI gives an error2024-03-21T13:27:23ZQuentin RaynaudRemoving a tag from the UI gives an error### Summary
As discussed in issue #432, I'm opening new issues for tag related misbehaviors I found.
Opening the tags list from `Repository/Tags`, then clicking on a tag, then clicking on the trash bin, then cliking on `Delete tag` is ...### Summary
As discussed in issue #432, I'm opening new issues for tag related misbehaviors I found.
Opening the tags list from `Repository/Tags`, then clicking on a tag, then clicking on the trash bin, then cliking on `Delete tag` is showing error `Gitlab::GitAccess::NotFoundError`.
### What is the expected *correct* behavior?
The tag should be deleted properly. Or the trash bin icon should not be available in the meantime.
#### Details about the Heptapod instance where the bug occurs
- Type of deployment (source, Docker, Omnibus, Heptapod Development Kit): Docker
- Exact Heptapod version: 0.20.2
I also add that the repo I use is pretty old so it is legacy and probably don’t use HGItaly except if you made something to convert those already. I think it's not the case so I feel it’s good to mention this.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/437Provide something like Git attributes2024-03-21T13:42:51ZGeorges RacinetProvide something like Git attributesThe checked-in `.gitattributes` file allows to control some aspects of the repository.
In particular, it is [interpreted by github-linguist](https://github.com/github/linguist/blob/master/docs/overrides.md), the engine taking care of pr...The checked-in `.gitattributes` file allows to control some aspects of the repository.
In particular, it is [interpreted by github-linguist](https://github.com/github/linguist/blob/master/docs/overrides.md), the engine taking care of programming language analysis, to provide exclusion for vendored libraries and direct detection rules.
As a practical example, `.t` files used for cram and Mercurial tests are detected as Perl by github-linguist.
There is even a [dedicated github-linguist issue](https://github.com/github/linguist/issues/1569) on the subject.
Projects like [Octobus' mercurial-devel](https://foss.heptapod.net/Octobus/mercurial-devel) and [evolve](https://foss.heptapod.net/mercurial/evolve) could force them to something more appropriate right now. The price to pay would be that it's called `.gitattributes` and that it probably wouldn't be forward compatible with how native Mercurial repositories will work in the not-so-far future.
There are potentially other use cases for a shared, checked-in configuration file, but we obviously should not call it`.gitattributes`. Does something similar already exist in Mercurial land that we could piggy-back on ? Should we introduce a `.heptapod-attributes`?Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/435Reschedule MR cleanups for native Mercurial projects2024-03-21T13:42:49ZGeorges RacinetReschedule MR cleanups for native Mercurial projectsA consequence of #423 is that Merge Requests special refs didn't get cleaned up as they should have, at first by failing (loudly), then by being ignored (still the case as of Heptapod 0.20.0).
We need to reschedule them in a background ...A consequence of #423 is that Merge Requests special refs didn't get cleaned up as they should have, at first by failing (loudly), then by being ignored (still the case as of Heptapod 0.20.0).
We need to reschedule them in a background migration after native Mercurial projects get proper support for special refs (#431), which should include deletion. This can be done with the `MergeRequests::CleanupRefsService.schedule` classmethod.
Normally these cleanups happen in `MergeRequests::PostMergeService` and `MergeRequests::CloseService`, hence we can perform them for all `closed` and `merged` MRs. We can expect the volume to be much lower than what this scheduling is designed for, but we can as well use it, provided we don't get failures if it fails (MR closed post #431, hence whose special refs are already cleaned up) or we just accept the failures and subsequent retries because they are low volume.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/427Fix Design Management repositories for Mercurial projects2024-03-21T13:27:25ZGeorges RacinetFix Design Management repositories for Mercurial projectsDesign Management features are using inner Git repositories with LFS for storage and versionning.
Acording to code comments, these repositories are supposed not to be "user-facing",
meaning most probably that they can't be pulled or pus...Design Management features are using inner Git repositories with LFS for storage and versionning.
Acording to code comments, these repositories are supposed not to be "user-facing",
meaning most probably that they can't be pulled or pushed to directly.
As with Snippets, it is probably wise just to let them be as expected by GitLab, i.e just Git repositories, but that's not what Heptapod currently does (to be confirmed):
Extract from `app/models/design_management/repository.rb`:
```ruby
module DesignManagement
class Repository < ::Repository
extend ::Gitlab::Utils::Override
# We define static git attributes for the design repository as this
# repository is entirely GitLab-managed rather than user-facing.
#
# Enable all uploaded files to be stored in LFS.
MANAGED_GIT_ATTRIBUTES = <<~GA.freeze
/#{DesignManagement.designs_directory}/* filter=lfs diff=lfs merge=lfs -text
GA
def initialize(project)
full_path = project.full_path + Gitlab::GlRepository::DESIGN.path_suffix
disk_path = project.disk_path + Gitlab::GlRepository::DESIGN.path_suffix
super(full_path, project, shard: project.repository_storage, disk_path: disk_path, repo_type: Gitlab::GlRepository::DESIGN)
end
```
So, the `container` (second argument in `super`) is the Project, which in case of Mercurial projects (native or not) will actually create Mercurial repositories. To fix that we'd need
- a special case in `Repository#initialize_raw_repository` or in `Gitlab::VCS.repository_class`
- to implement `vcs_type` (-> `git`) and `mercurial?` (-> `false`) directly on `DesignManagement::Repository` and check that we never call `repository.container.vcs_type` directly and same with `mercurial?`Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/414Only protected branches should be published2024-03-21T13:42:50ZDan Villiom Podlaski Christiansendanchr@gmail.comOnly protected branches should be published### Proposal
I've used both GitLab itself and GitHub, relying on both protected branches and routine force-pushes to unprotected branches. Essentially, both consider a protected branch something that you can neither delete nor force-pu...### Proposal
I've used both GitLab itself and GitHub, relying on both protected branches and routine force-pushes to unprotected branches. Essentially, both consider a protected branch something that you can neither delete nor force-push.
The closest equivalence to this “branch protection” — which isn't really a Git concept — is public changesets in Mercurial. The same guarantees apply; once a public changeset is pushed, that's it, and you can never unpublish it, short of administrative action.
So, when first using Heptapod, I was rather surprised to learn that it's [auto-publishing except for topics](https://heptapod.net/pages/faq.html#bare-draft). What is the point of exposing “protected branches” in the UI, if it has no effect?
(As an aside, this also makes it harder to interact with any remote repositories using hg-git, as that requires bookmarks and draft changesets. But I have no actual use for that right now.)Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/413Merge Request pipeline link2024-03-21T13:27:24ZGeorges RacinetMerge Request pipeline linkAfter a change of source branch in a Merge Request (which is Heptapod specific), it seems that the MR cannot find its existing pipelines any more: we get a perpetual spin wheel instead of the pipelines widget, and cannot merge from the i...After a change of source branch in a Merge Request (which is Heptapod specific), it seems that the MR cannot find its existing pipelines any more: we get a perpetual spin wheel instead of the pipelines widget, and cannot merge from the interface (red button, as with conflicts)
Just got that with py-heptapod!50 and I was already suspecting something along those lines.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/406Choice of VCS in multiple imports from manifest file2024-03-21T13:27:25ZGeorges RacinetChoice of VCS in multiple imports from manifest fileAfter #405, we'll be faced with the fact that the multiple imports feature is Mercurial-centric in Heptapod, and of course, we'd like to import Git repositories as well.
Either we'll have to let the user specify it, or we'll start if po...After #405, we'll be faced with the fact that the multiple imports feature is Mercurial-centric in Heptapod, and of course, we'd like to import Git repositories as well.
Either we'll have to let the user specify it, or we'll start if possible with a simple detection phase.
Given that repositories to import are given by URLs, it's rather easy to check if they are Git or Mercurial. How to include that in the creation flow is where the difficulty can be.Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/400Mercurial project templates2024-03-21T13:26:19ZGeorges RacinetMercurial project templatesWith GitLab 13.7, the project templates become more prominent in the creation page, because users have to choose explicitely between "blank", "template" and "import", instead of being in the "blank" (used to be called "empty") creation f...With GitLab 13.7, the project templates become more prominent in the creation page, because users have to choose explicitely between "blank", "template" and "import", instead of being in the "blank" (used to be called "empty") creation form.
Perhaps it's time to introduce Mercurial project templates, or at the very minimum check if a user-defined template can be Mercurial, in other words: that templates can have `vcs_type` fields.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/389Import/export: take care of readthedocs integration2024-03-21T13:27:25ZGeorges RacinetImport/export: take care of readthedocs integrationSpotted by RSpec tests, in the same job as linked from #388.
Will probably require some testing of the resulting export (and import) that we aren't able to do before Heptapod 0.18.0rc1Spotted by RSpec tests, in the same job as linked from #388.
Will probably require some testing of the resulting export (and import) that we aren't able to do before Heptapod 0.18.0rc1Heptapod 1.3.2https://foss.heptapod.net/heptapod/hgitaly/-/issues/24CommitService: implement commit signatures methods2022-01-26T15:18:33ZGeorges RacinetCommitService: implement commit signatures methodsAs of this writing, these are currently `GetCommitSignatures` and `FilterShasWithSignatures`
Integration with commit signing is generally unclear at this point.
It is a bug to stumble on this at the %"HGitaly1: Hg SHAs" stage.As of this writing, these are currently `GetCommitSignatures` and `FilterShasWithSignatures`
Integration with commit signing is generally unclear at this point.
It is a bug to stumble on this at the %"HGitaly1: Hg SHAs" stage.HGitaly3: fully in chargehttps://foss.heptapod.net/heptapod/heptapod/-/issues/355Git push mirroring for native Mercurial repositories2024-03-21T13:42:50ZGeorges RacinetGit push mirroring for native Mercurial repositoriesNative repositories won't have an inner Git repository that can be used to mirror to external Git services as people mention in #125.
In order for that important feature to keep working, we'll simply have to move the conversion to Git i...Native repositories won't have an inner Git repository that can be used to mirror to external Git services as people mention in #125.
In order for that important feature to keep working, we'll simply have to move the conversion to Git inside the push-mirroring asynchronous job.
This is not an immediate concern: at best, native repositories will be available as an option for new projects in %"Heptapod 0.17.0" (perhaps only if a given feature flag is activated). In a subsequent release, we would turn it into the default, and yet in another one take care of migrating existing hg-git based repositories to native ones.
I'm assigning this to %"Heptapod 1.0" to help not forgetting about it, but in truth, it won't really be needed by that time.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/333User feedback for commits introduced by Merge Requests2024-03-21T13:26:41ZGeorges RacinetUser feedback for commits introduced by Merge RequestsQuoting @muxator on mercurial/hg-git!38:
> There is probably a UI bug in Heptapod. Before merging, I rebased this PR to keep the history linear. Yet the web UI showed that merging this PR would have created 3 commits: 2 normal ones and ...Quoting @muxator on mercurial/hg-git!38:
> There is probably a UI bug in Heptapod. Before merging, I rebased this PR to keep the history linear. Yet the web UI showed that merging this PR would have created 3 commits: 2 normal ones and a merge commit. Upon merging, Heptapod did the right thing and no merge commit was created. This could have been much disorienting to a newcomer.
I've actually known about this for a long time, but never got around filing it properly.
In the Git case, the merge commit would be systematic with the `:merge` merge method.
It's probably harder to fix than it looks, depending how much of that display is implemented in JavaScript. Also, it's possible that the piece of code handling the display wouldn't have access to the information whether the MR is actually linear or not. In that case, I suppose being less definitive in the message would be the best thing to do.Heptapod 1.4https://foss.heptapod.net/heptapod/hgitaly/-/issues/3Server process: TLS2022-01-26T15:18:34ZGeorges RacinetServer process: TLSFor #1 we bound to the TCP socket as in the [standard example](https://grpc.io/docs/languages/python/basics/#starting-the-server), with `server.add_insecure_port()`. As the name suggests, this is probably without any TLS option, but I di...For #1 we bound to the TCP socket as in the [standard example](https://grpc.io/docs/languages/python/basics/#starting-the-server), with `server.add_insecure_port()`. As the name suggests, this is probably without any TLS option, but I didn't check that yet.
We'll need TLS support for multiple server ("cloud-native") deployments, but there's no urgency, we don't have it for the `hgserve` HTTP repository server either.HGitaly3: fully in chargehttps://foss.heptapod.net/heptapod/heptapod/-/issues/285Branch creation in the Web IDE2024-03-21T13:27:23ZGeorges RacinetBranch creation in the Web IDEThe Web IDE mostly works, but it has problems with branch creation:
In short the only mode that works is if the user has enough rights to commit changes on the current branch.
1. the default placeholder branch name looks like `USER-bran...The Web IDE mostly works, but it has problems with branch creation:
In short the only mode that works is if the user has enough rights to commit changes on the current branch.
1. the default placeholder branch name looks like `USER-branch/default-patch-NNNN` where `NNNN` is some number, mostly random. Heptapod will refuse to create such a branch, and that's a good thing. We should have a `topic/default/user-NNNN` instead, and (obviously) actually create a topic.
2. by default, it's meant to produce a Merge Request. We did not yet check if a fork was entailed, because of 1.
About problem 1, there are at least three different places in the code that produce such branch names, including in JavaScripts. That's not really a surprise, but we're blocked here because we can't deploy changes in these (Omnibus).Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/284Merge Request targeting a topic2024-03-21T13:42:51ZGeorges RacinetMerge Request targeting a topicThere's nothing that prevents the target GitLab branch of a Merge Request to be a topic.
Many people would probably consider bad practice to target a topic, but I wouldn't go as far as calling them illegitimate.
The outcome would be su...There's nothing that prevents the target GitLab branch of a Merge Request to be a topic.
Many people would probably consider bad practice to target a topic, but I wouldn't go as far as calling them illegitimate.
The outcome would be surprising for most users: accepting the Merge Request will publish its final changeset, hence in particular the target topic.
I think a full consistent behaviour for MRs creating non-linear history would be:
1. not publish, that's the important part.
2. generate the final merge in the target topic
It's less clear in linear cases:
1. with the default merge method, we should be able to generate an empty merge changeset, but that's to be checked
2. what should it mean with the 'fast-forward' method? Nothing? Adoption of the source changesets in the target topic?
The risk of unwanted publication has been on my mind for a while, but I don't think it's been reported before.
It's too late for %"Heptapod 0.13.0" to offer full support for these (especially in the linear case), but I'd want to include at least a basic protection, so that users don't get bad surprises.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/283Generic outgoing web hook for Mercurial2024-03-21T13:42:49ZGeorges RacinetGeneric outgoing web hook for MercurialCurrently Heptapod sends GitLab's generic web hook content (full of `ref/heads` and similar Git idioms) together with one added information for the true Mercurial branch.
This is at best confusing. While some knowledgeable people may fi...Currently Heptapod sends GitLab's generic web hook content (full of `ref/heads` and similar Git idioms) together with one added information for the true Mercurial branch.
This is at best confusing. While some knowledgeable people may find a way to leverage it, we will need a format meant for Mercurial.
Scheduling for 0.14.0 because
- in that version the Rails app will stop seeing a Git repository by default – hence providing Git-style content won't be a side effect any more, it would be a deliberate effort
- we need some time to think about the format. We can probably find inspiration in other Mercurial hosting systems, but we'll also probably want to make topics and phases more prominent than they probably are elsewhere.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/239Implement the revert option2024-03-21T13:42:49ZGeorges RacinetImplement the revert optionSimilarly to cherry-picks, we have an option visible on merged Merge Requests to revert. Internally it's more related to commits.
In #219, we've replaced the whole modal dialog with an explicit admission that it's not implemented.
Now, ...Similarly to cherry-picks, we have an option visible on merged Merge Requests to revert. Internally it's more related to commits.
In #219, we've replaced the whole modal dialog with an explicit admission that it's not implemented.
Now, let's do it:
- [ ] core implementation, maybe tested with the REST API
- [ ] UI: restoration of the modal dialogHeptapod 1.4