heptapod issueshttps://foss.heptapod.net/heptapod/heptapod/-/issues2023-07-25T12:33:18Zhttps://foss.heptapod.net/heptapod/heptapod/-/issues/187"Where is the fork button?"2023-07-25T12:33:18ZPierre Augier"Where is the fork button?"Currently the Fork button is hidden because forking is not supported by Heptapod and Heptapod workflow is not based on forks.
Many people used to Github / Gitlab / Bitbucket look for a Fork button. I had some questions on that by people...Currently the Fork button is hidden because forking is not supported by Heptapod and Heptapod workflow is not based on forks.
Many people used to Github / Gitlab / Bitbucket look for a Fork button. I had some questions on that by people looking at our new repositories on foss.h.n.
Some people who don't find the Fork button won't ask.
A solution could be to have the standard Fork button, but that it triggers the apparition of a text explaining the situation and giving links about the Heptapod workflow. It could be better than no Fork button.https://foss.heptapod.net/heptapod/heptapod/-/issues/132Merge via webui adds a merge commit - expected rebase and publish2024-03-21T13:42:49ZArthur LutzMerge via webui adds a merge commit - expected rebase and publishSince upgrade to 0.7.0rc (we need to check if this was not the case on 0.6.x).
From :
```mermaid
graph BT
A --> B
A[init]
B[topic1]
A --> C
C[topic2]
```
I click merge on topic2 then topic1 in the web UI, I get :
```mermaid
gra...Since upgrade to 0.7.0rc (we need to check if this was not the case on 0.6.x).
From :
```mermaid
graph BT
A --> B
A[init]
B[topic1]
A --> C
C[topic2]
```
I click merge on topic2 then topic1 in the web UI, I get :
```mermaid
graph BT
A --> B
A(init)
B(topic1)
A --> C
C(topic2)
C --> D
B --> D
D(Merge branch 'topic/default/topic2 into 'branch/default')
```
I would expect
```mermaid
graph BT
A --> C
A(init)
B(topic1)
C --> B
C(topic2)
```Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/124[doc] Shorter topics tutorial2023-07-24T15:06:23ZArthur Lutz[doc] Shorter topics tutorialMy every day use of topics seems much simpler than what I find in https://www.mercurial-scm.org/doc/evolution/tutorials/topic-tutorial.html which I send to new heptapod users.
It would be nice to have a simpler tutorial available which...My every day use of topics seems much simpler than what I find in https://www.mercurial-scm.org/doc/evolution/tutorials/topic-tutorial.html which I send to new heptapod users.
It would be nice to have a simpler tutorial available which talks about :
* start a topic
* assign a topic to existing changesetshttps://foss.heptapod.net/heptapod/heptapod/-/issues/63Merge request depending to draft ancestors should not be published without wa...2024-03-21T13:42:49ZElouan MartinetMerge request depending to draft ancestors should not be published without warning### Summary
During the development of a feature, in its own topic, it may happen (in a rare and not very good workflow) that you write a second "sub"-feature and create a merge request onto that topic.
By merging that MR, it'll publish...### Summary
During the development of a feature, in its own topic, it may happen (in a rare and not very good workflow) that you write a second "sub"-feature and create a merge request onto that topic.
By merging that MR, it'll publish all ancestor topics without a warning.
NB: This has happened to me as a newcomer to Mercurial in a real work repo, I wasn't aware of phases. :smiley:
### Steps to reproduce
* Draft commit in a new topic `foo`
* Draft commit in a new topic `bar`, descendant of `foo`'s commit
* Create a merge request from `bar` topic to `foo`
* Merge it!
### Actual result
All these draft commits get published.
### Expected behavior
Multiple behavior may be chosen:
* Warn that ancestor topic (or rather the based commit) is a draft and, either:
* prevent merging
* confirm that merging will publish ancestors too
* Rebase instead of merge to keep it draft
It has been suggested that behavior could be different if ancestors got existing merge requests, e.g. by linking to these. At least work in progress should probably prevent publishing. Also, ancestor merge requests that now reference published commits may be considered obsolete.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/1254Web UI for VCS Type stats2024-03-21T13:42:48ZGeorges RacinetWeb UI for VCS Type statsThis is a follow-up to #471, after which we have an API endpoint, but no direct display in the admin dashboard.This is a follow-up to #471, after which we have an API endpoint, but no direct display in the admin dashboard.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/1190Git projects have Mercurial Publisher in protected branches and tags roles2024-03-21T13:27:26ZGeorges RacinetGit projects have Mercurial Publisher in protected branches and tags rolesBecause GitLab 16.0 comes with refactorings related to the adding of the Instance Admins case to the roles selectable in protected branches and tags project settings, I have reason to believe the Mercurial specific role could be displaye...Because GitLab 16.0 comes with refactorings related to the adding of the Instance Admins case to the roles selectable in protected branches and tags project settings, I have reason to believe the Mercurial specific role could be displayed even on Git repositories.
This is ~~worth checking before finalization of a Heptapod version based on GitLab 16.x~~ confirmed on Heptapod 0.40.0, hence a minor UI bug.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/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/618Page title refers to GitLab instead of Heptapod2022-02-01T13:13:24ZPacien TRAN-GIRARDPage title refers to GitLab instead of HeptapodMinor issue, on all pages.Minor issue, on all pages.https://foss.heptapod.net/heptapod/heptapod/-/issues/617Unhelpful error when creating release with tag protection2024-03-21T13:27:24ZDan Villiom Podlaski Christiansendanchr@gmail.comUnhelpful error when creating release with tag protection<!---
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
<!-- Summarize the bug encountered concisely. -->
I tried creating a release using the UI, but got an error. The failing request seems to say “access defined” even though I'm maintainer? I seem to recall succeeding in doing this earlier; maybe if I didn't fill out the milestone?
### Steps to reproduce
<!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. -->
1. Go to https://foss.heptapod.net/mercurial/hg-git/-/releases/new
2. Fill in the data as describe in the screenshot in the bottom.
3. Submit!
### Example Project
<!-- If possible, please create an example project here on foss.heptapod.net or over at heptapod.host that exhibits the problematic
behavior, and link to it here in the bug report. If you are using an older version of Heptapod, this
will also determine whether the bug is fixed in a more recent version. -->
I do not have project creation rights, but it happens with hg-git.
### What is the current *bug* behavior?
<!-- Describe what actually happens. -->
I cannot create a release; I get no useful error.
### What is the expected *correct* behavior?
<!-- Describe what you should see instead. -->
I either succeed in creating a release or get a meaningful error telling me why I can't do so.
### Relevant logs and/or screenshots
<!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code
as it's tough to read otherwise. -->
The request:
```
curl 'https://foss.heptapod.net/api/graphql' \
-X 'POST' \
-H 'Content-Type: application/json' \
-H 'Accept: */*' \
-H 'Accept-Language: en-gb' \
-H 'Accept-Encoding: gzip, deflate, br' \
-H 'Host: foss.heptapod.net' \
-H 'Origin: https://foss.heptapod.net' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15' \
-H 'Referer: https://foss.heptapod.net/mercurial/hg-git/-/releases/new' \
-H 'Content-Length: 883' \
-H 'Connection: keep-alive' \
-H 'Cookie: <snip>' \
-H 'X-CSRF-Token: <snip>' \
-H 'x-gitlab-feature-category: release_orchestration' \
--data-binary '[{"operationName":"createRelease","variables":{"input":{"projectPath":"mercurial/hg-git","tagName":"0.10.4","name":"0.10.4","description":"This is a minor release, focusing on bugs and compatibility.\n\nBug fixes:\n\n* Fix compatibility with the ``mercurial_keyring`` extension. (#360)\n* Add missing test files to the source archive. (#375)\n* Fix tests with Git 2.34.\n","milestones":["0.10.4"],"ref":"branch/default","assets":{"links":[{"name":"PyPI release","url":"https://pypi.org/project/hg-git/0.10.4/","linkType":"OTHER"},{"name":"Python wheel","url":"https://foss.heptapod.net/mercurial/hg-git/-/packages/138","linkType":"PACKAGE"}]}}},"query":"mutation createRelease($input: ReleaseCreateInput!) {\n releaseCreate(input: $input) {\n release {\n links {\n selfUrl\n __typename\n }\n __typename\n }\n errors\n __typename\n }\n}\n"}]'
```
The response:
```json
[
{
"data": {
"releaseCreate": {
"release": null,
"errors": [
"Access Denied"
],
"__typename": "ReleaseCreatePayload"
}
}
}
]
```
![Screenshot_2022-01-26_at_19.20.27](/uploads/0a2e32ff4ce5337e5eae3e616547be48/Screenshot_2022-01-26_at_19.20.27.png)
#### Details about the Heptapod instance where the bug occurs
<!-- If you don't have a reproduction on foss.heptapod.net nor heptapod.host,
please post some details about the instance exhibiting the problem
- Type of deployment (source, Docker, Omnibus, Heptapod Development Kit)
- Exact Heptapod version
- For source deployments, all possibly relevant versions.
On source production instances, one can get lots of information by running
```
bundle exec rake gitlab:env:info RAILS_ENV=production
```
from the Rails application directly, with the same system user that runs
it normally.
In the case of the Heptapod Development Kit, use this from the Rails
application repository:
```
bundle exec rake gitlab:env:info RAILS_ENV=production
```
-->
This happens on the FOSS instance.
### Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem. -->Heptapod 1.3.2Georges RacinetGeorges Racinethttps://foss.heptapod.net/heptapod/heptapod/-/issues/564UI for Mercurial pull mirrors2024-03-21T13:42:50ZGeorges RacinetUI for Mercurial pull mirrorsThe pull mirrors introduced for #306 can only be created through the REST API.The pull mirrors introduced for #306 can only be created through the REST API.Heptapod 1.4https://foss.heptapod.net/heptapod/heptapod/-/issues/557Wiki "clone repository" help page still mentions git2021-10-25T12:40:49ZPacien TRAN-GIRARDWiki "clone repository" help page still mentions gitThe instructions on the help page at `[instance]/[group]/[project]/-/wikis/git_access` all mention the `git` command instead of `hg`.The instructions on the help page at `[instance]/[group]/[project]/-/wikis/git_access` all mention the `git` command instead of `hg`.https://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/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/heptapod/-/issues/327Adapt empty tags page for Mercurial2020-08-04T16:55:49ZGeorges RacinetAdapt empty tags page for MercurialCurrently, it says:
> Use git tag command to add a new one:
> `git tag -a v1.4 -m 'version 1.4'`
It should be rework to display proper instructions if the Project is Mercurial
Extracted from #20 (catch-all issues for such questions)Currently, it says:
> Use git tag command to add a new one:
> `git tag -a v1.4 -m 'version 1.4'`
It should be rework to display proper instructions if the Project is Mercurial
Extracted from #20 (catch-all issues for such questions)https://foss.heptapod.net/heptapod/heptapod/-/issues/171Finish Mercurial command-line merge instructions2020-08-04T17:02:33ZGeorges RacinetFinish Mercurial command-line merge instructionsThis is a follow-up to #28, of which a bare minimal version has been done for Heptapod 0.8.1This is a follow-up to #28, of which a bare minimal version has been done for Heptapod 0.8.1https://foss.heptapod.net/heptapod/heptapod/-/issues/137Review "Suggest changes" - in GitLab 11.62024-03-21T13:27:25ZArthur LutzReview "Suggest changes" - in GitLab 11.6https://docs.gitlab.com/ce/user/discussions/#suggest-changes
```
As a reviewer, you’re able to suggest code changes with a simple Markdown syntax in Merge Request Diff threads.
Then, the Merge Request author (or other users with approp...https://docs.gitlab.com/ce/user/discussions/#suggest-changes
```
As a reviewer, you’re able to suggest code changes with a simple Markdown syntax in Merge Request Diff threads.
Then, the Merge Request author (or other users with appropriate permission) is able to apply these suggestions with
a click, which will generate a commit in the Merge Request authored by the user that applied them.
```
Just to track this feature for heptapod (I know there's quite a road to 11.6).Heptapod 1.3.2https://foss.heptapod.net/heptapod/heptapod/-/issues/100Branch view should be more mercurial-like and less git like2023-07-24T14:59:43ZMaciej FijalkowskiBranch view should be more mercurial-like and less git likeRight now the branch view in heptapod follows git standard of branches, more or less equivalent to `ancestors(branch)`. In my opinion, the branch view should just show commits from this branch - something equivalent to `hg log -b <branch>`Right now the branch view in heptapod follows git standard of branches, more or less equivalent to `ancestors(branch)`. In my opinion, the branch view should just show commits from this branch - something equivalent to `hg log -b <branch>`https://foss.heptapod.net/heptapod/heptapod/-/issues/39Merge request should only show diff for topic, not previous topics2023-07-25T12:45:12ZGeorges RacinetMerge request should only show diff for topic, not previous topicsFor the following topology of changesets :
* [draft] (topic-2) add topic-2 feature
* [draft] (topic-1) add topic-1 feature
* [public] initial commit
When pushed to heptapod, two merge requests can be created. The first one is fine, on...For the following topology of changesets :
* [draft] (topic-2) add topic-2 feature
* [draft] (topic-1) add topic-1 feature
* [public] initial commit
When pushed to heptapod, two merge requests can be created. The first one is fine, only the diff for topic-1 is there.
For the second one it show both topic-2 and topic-1. It would be nice if it could only show topic-2.
A tricky part of this is then when I click merge on topic-2 one might expect to have:
* [draft] (topic-1) add topic-1 feature
* [public] (topic-2) add topic-2 feature
* [public] initial commithttps://foss.heptapod.net/heptapod/heptapod/-/issues/23Button to display the obsolete revisions in the graph2023-07-24T13:55:10ZGeorges RacinetButton to display the obsolete revisions in the graph**Problem**
Mercurial hides obsolete revisions by default, but they are visible in the graph.
**Task description**
Add a button on the graph view which toggles the visibility of obsolete revisions.**Problem**
Mercurial hides obsolete revisions by default, but they are visible in the graph.
**Task description**
Add a button on the graph view which toggles the visibility of obsolete revisions.