May be considered a "bug" as missing functionality, but since it's being *added* to a feature that didn't include this in the original proposal...Feature? ### Problem to solve `/create_merge_request` only provides an argument for the new branch's name, using the project's default branch as the source of the new branch and target of the MR. i frequently use this feature, but have to use the button/panel interface instead of the QA because i can't choose the origin/target branch. It only uses the project's default branch. In my case, that's `master` (i'm open to guidance for a better setup...) so all new MRs would target that. Not desirable. Besides, "default" implies permissible substitutions. Since i'm running an internal instance of CE, i can't easily coordinate *issues* in a natural hierarchy, so i work around it with labeling and branch structure. Each release cycle gets a `release_##` branch targeting `master`. An Epic becomes a branch targeting the release, then any children of the Epic target the Epic's branch and so on. ### Intended users Mostly intended for project coordinators and developers. ### User experience goal For users who are efficient with typing and make regular use of quick-actions, this change would improve the unified way to type up an issue (or comment) and modify attributes of the issue from one space. It would also streamline creating issues from templates. ### Proposal The `/create_merge_request` quick action should provide functional parity with the visual component, allowing a user to select both a name for the issue's branch *and* the branch origin/MR target. ### Permissions and Security This change would not change existing access to the `/create_merge_request` quick action. i find it unlikely that specific *attributes* of a quick action are controllable with Role permissions anyway. Are QAs manageable by Role at all? :confused: ### Documentation Current syntax of `/create_merge_request`: ``` /create_merge_request [branch name] ``` Proposed change: ``` /create_merge_request [auto|branch-name|"branch-name"] [default|target-branch|"target-branch"] ``` * An argument value is parsed to the first space character unless enclosed in quotes. * Even when enclosed, branch names must still contain legal characters * (suggested) Spaces within quotes COULD be converted to legal `-` or `_` * Examples * Automatic selection of new branch name and target (project default) ``` /create_merge_request /create_merge_request auto /create_merge_request auto default ``` * Specified new branch name, target is project default ``` /create_merge_request new-branch-name /create_merge_request "new branch name" /create_merge_request new-branch-name default /create_merge_request "new branch name" default ``` * Auto branch, specified target ``` /create_merge_request auto some-other-branch /create_merge_request auto "some other branch" ``` * Both arguments specified ``` /create_merge_request new-branch-name some-other-branch /create_merge_request "new branch name" "some other branch" /create_merge_request new-branch-name "default" /create_merge_request "auto" "default" ``` * INVALID (see **links/references**) ``` /create_merge_request "" "" /create_merge_request unprotected new branch /create_merge_request bad^branch^name worse origin name /create_merge_request "still^bad^branch^name" etc. ``` Note the cases where the argument keywords are enclosed in quotes `" "`. Like other special markup tags, enclosed strings are treated as literals. Example label: `~"Dumb label!123"` does not parse a link to MR 123. If there's *really* a need to use "auto" and "default" as branch names, so be it. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? Successful completion provides identical functionality between the visual `[Create Merge Request]` button/panel and the `/create_merge_request` quick action. ### Links / references * This appears to be the original(?) request for `/create_merge_request` quick action: gitlab-foss#40085 * Legal branch names: https://wincent.com/wiki/Legal_Git_branch_names <br> For purposes of treating `" "` enclosed strings