heptapod issueshttps://foss.heptapod.net/heptapod/heptapod/-/issues2024-03-21T13:26:41Zhttps://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/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/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