heptapod issueshttps://foss.heptapod.net/heptapod/heptapod/-/issues2024-03-21T13:42:50Zhttps://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/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/366heptapod lacks several improvements when working with stacked topics2022-11-19T12:27:18ZBramheptapod lacks several improvements when working with stacked topics### Summary
When stacking topics for various reason when doing multiple parallels topic aren't possible, heptapod's UI lacks lacks several improvements:
* url displayed on "hg push" always point to the base branch, not to the directly ...### Summary
When stacking topics for various reason when doing multiple parallels topic aren't possible, heptapod's UI lacks lacks several improvements:
* url displayed on "hg push" always point to the base branch, not to the directly previous topic
* when create a MR on the web UI, the base branch is also always suggested instead of the next topic, thus creating a MR with a huge diff where it should only be the targeted commits
* when merging a MR, its topic is deleted by default, thus, if another MR was targeting this topic it will now be broken
### Steps to reproduce
Go on a project, then:
- hg commit -m "a"
- hg topic -r tip "a"
- hg commit -m "b"
- hg topic -r tip "b"
- hg push
"hg log" will look like this:
```
@ 19 9ad89ae3d882 draft (branch: default) (topic: b) "b"
|
o 17 adbffc757607 draft (branch: default) (topic: a) "a"
|
o 14 aecf2a0e138a public (branch: default) "old commit message"
|
```
You will have this kind of message in cli:
```
pushing to https://my.heptapod.tld/orga/project
searching for changes
OBSEXC: computing relevant nodes
OBSEXC: looking for common markers in 14 nodes
OBSEXC: computing markers relevant to 2 nodes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 1 files
remote: 3 new obsolescence markers
remote: To create a merge request for topic/default/a, visit:
remote: https://my.heptapod.tld/orga/project/-/merge_requests/new?merge_request%5Bsource_branch%5D=topic%2Fdefault%2Fa&merge_request%5Btarget_branch%5D=branch%2Fdefault
remote: To create a merge request for topic/default/b, visit:
remote: https://my.heptapod.tld/orga/project/-/merge_requests/new?merge_request%5Bsource_branch%5D=topic%2Fdefault%2Fb&merge_request%5Btarget_branch%5D=branch%2Fdefault
```
Also try to create a MR.
### What is the current *bug* behavior? What is the expected *correct* behavior?
The url to create a MR for topic "b" is:
```
remote: To create a merge request for topic/default/b, visit:
remote: https://my.heptapod.tld/orga/project/-/merge_requests/new?merge_request%5Bsource_branch%5D=topic%2Fdefault%2Fb&merge_request%5Btarget_branch%5D=branch%2Fdefault
```
It should be:
```
remote: To create a merge request for topic/default/b, visit:
remote: https://my.heptapod.tld/orga/project/-/merge_requests/new?merge_request%5Bsource_branch%5D=topic%2Fdefault%2Fb&merge_request%5Btarget_branch%5D=topic%2Fdefault%2a
```
Same, when creating a MR from the web UI, the default targeted branch for topic/default/b should be topic/default/a and not branch/default
Also, if the MR for topic/default/b is correctly pointing to topic/default/a and topic/default/a also have a MR, merging topic/default/a MR will delete it topic and breaks topic/default/b becaust its targeted branch doesn't exist anymore, it should have automatically be changed to branch/default
Those little frictions are making it hard for us to move to a full web ui based usage of heptapod for MRs handling instead of doing it in cli but, nevertheless, heptapod is already great and has been a great improvement for us at logilab, thx a lot :)https://foss.heptapod.net/heptapod/heptapod/-/issues/329Editing files through the web and creating merge requests and topics - topic ...2024-02-13T11:55:43ZArthur LutzEditing files through the web and creating merge requests and topics - topic nameSince a recent release of heptapod editing through the web interface to contribute a change, a merge request and a new hg topic works ! :tada:
But...
One needs to know that the branch name should be `topic/default/topic-name`, else i...Since a recent release of heptapod editing through the web interface to contribute a change, a merge request and a new hg topic works ! :tada:
But...
One needs to know that the branch name should be `topic/default/topic-name`, else it fails (if needed I can find the error generated).
Maybe a help string and a validator could be a first step to help the user.
A second step would be to convert the branch name entered by the user into `topic/default/typed-branch-name` ?https://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/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/185Allow bookmark deletions2023-07-25T05:58:25ZPierre AugierAllow bookmark deletionsRepositories imported can contain bookmarks (see #143) and since they are protected, they are not going to move. It is quite inconvenient, especially for bookmarks as meaningful as master.
https://foss.heptapod.net/fluiddyn/fluidsim/bra...Repositories imported can contain bookmarks (see #143) and since they are protected, they are not going to move. It is quite inconvenient, especially for bookmarks as meaningful as master.
https://foss.heptapod.net/fluiddyn/fluidsim/branches
I'd like to delete the bookmark master, but:
```
pierre@kth ~/t/fluidsim> hg bookmarks
master 1264:e37c77fc8020
pierre@kth ~/t/fluidsim> hg book master -d
pierre@kth ~/t/fluidsim> hg bookmarks
no bookmarks set
pierre@kth ~/t/fluidsim> hg push -B master
pushing to ssh://hg@foss.heptapod.net/fluiddyn/fluidsim
searching for changes
no changes found
remote: Creating or updating bookmarks is forbidden by default in Heptapod. See https://heptapod.net/pages/faq.html#bookmarks to learn why and how to partially lift that restriction
abort: push failed on remote
```https://foss.heptapod.net/heptapod/heptapod/-/issues/178stripping commits2023-07-25T05:50:26ZMatti Picusstripping commitsThe Bitbucket UI allows an admin to strip commits from a repo. This is convenient as hg does not really support force pushing. If a push or merge is done by mistake to one of the long lived mercurial branches, it is convenient to be able...The Bitbucket UI allows an admin to strip commits from a repo. This is convenient as hg does not really support force pushing. If a push or merge is done by mistake to one of the long lived mercurial branches, it is convenient to be able to rollback those commits.
Is this on the heptapod roadmap? Should I file an issue on a different repo?https://foss.heptapod.net/heptapod/heptapod/-/issues/163Provide read-only access to hgweb-API2023-07-24T15:38:56ZAndré KlitzingProvide read-only access to hgweb-API### Description
We are using Review Board as a review system. It requires access to the Mercurial repository over local hg binary or the json-api from hgweb.
At the moment we use Kallithea and a separate hgweb server to access the API.
...### Description
We are using Review Board as a review system. It requires access to the Mercurial repository over local hg binary or the json-api from hgweb.
At the moment we use Kallithea and a separate hgweb server to access the API.
### Proposal
I like to request that heptapod provides a read-only access to hgweb.
### Links / references
https://www.mercurial-scm.org/repo/hg/?style=gitweb
https://www.mercurial-scm.org/repo/hg/?style=jsonhttps://foss.heptapod.net/heptapod/heptapod/-/issues/147Support direct push creation2023-07-24T15:36:05ZGeorges RacinetSupport direct push creationIn the 10.5.0 version, GitLab got automatic creation of Git repos by a direct push,
see [the MR](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/16547) and the [changelog](/heptapod/heptapod/blob/branch/heptapod-0-8/CHANGELOG.md...In the 10.5.0 version, GitLab got automatic creation of Git repos by a direct push,
see [the MR](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/16547) and the [changelog](/heptapod/heptapod/blob/branch/heptapod-0-8/CHANGELOG.md)
Notably, this changes `gitlab_access.rb` so that it can handle the security question for
a repo that doesn't exist yet, making the interface of our `hg_access.rb` diverge from it.
It would probably be nice to have this feature as well, or at least to close the gap between these two access control objects.
Noticed while working on !45https://foss.heptapod.net/heptapod/heptapod/-/issues/146Some permission user feedbacks get lost2023-07-24T15:34:34ZGeorges RacinetSome permission user feedbacks get lostIn standard GitLab, push denies come with an explicit reason, which range from
not very interesting "You are not allowed to upload code for this project" to actually useful "The repository is temporarily read-only".
The way permission c...In standard GitLab, push denies come with an explicit reason, which range from
not very interesting "You are not allowed to upload code for this project" to actually useful "The repository is temporarily read-only".
The way permission checks work currently in Heptapod, except for the general access/visibility check, GitLab has no idea what the user is trying to do, and can only pass over a permission level to be used by Mercurial.
Hence these user feedbacks are lost. This isn't a big concern for the time being, and there's not so much we can do about it short time, but it's perhaps something we can improve within the hgitaly project.https://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/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/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/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.4