forgejo-contrib-forgejo-cli-issues-244.md
Watch20
Star402
Fork
You've already forked forgejo-cli
CodeIssues 44Pull requests 8Releases 11Packages 2WikiActivity
fj pr create#244Open
opened 2025-12-03 21:20:05 +01:00 by LordMZTE · 4 comments
LordMZTE commented 2025-12-03 21:20:05 +01:00
Collaborator
Copy link
I just created my first PR using the CLI, and I noticed a couple things about the UI that could really do with some improvement:
Error: title is required
Location:
src/prs.rs:1071:27
Not sure, haven't checked the code for this one.
I just created my first PR using the CLI, and I noticed a couple things about the UI that could really do with some improvement: - If the PR consists of only one commit, we should default the title of the PR to the commit message and the body of the PR to further lines of the commit text (if any). The web UI does this too. In fact, I'm not quite sure what it does for PRs with multiple commits. - Before creating the PR, print out information about the PR we're about to create and ask the user to confirm. We should especially do this if the PR body is left empty in the editor. This would match the behavior of Git for creating commits. I actually assumed this was the case at first and accidentally created a PR prematurely as there seems to be no way to abort the process after the editor has been opened for the body. - Generally, the UI could be more interactive. We could, for example, make the TITLE argument optional and ask the user if it isn't provided. It seems like we already make some attempt to guess a title, because instead of a normal arg parsing error, I got this when I left it out: Error: title is required Location: src/prs.rs:1071:27 Not sure, haven't checked the code for this one.
Cyborus commented 2025-12-03 22:49:54 +01:00
Member
Copy link
If the PR consists of only one commit, we should default the title of the PR to the commit message and the body of the PR to further lines of the commit text (if any). The web UI does this too. In fact, I'm not quite sure what it does for PRs with multiple commits.
I added this in !223, though it isn't the default, it requires setting the flag. It also doesn't work with AGit yet, but I have looked some into how to do that. That fills in the commit body by default when opening the editor too, even without the flag set.
Before creating the PR, print out information about the PR we're about to create and ask the user to confirm.
I had thought of printing out the PR in the same style as fj pr view after it was created, but a confirmation dialogue there is also interesting...
We should especially do this if the PR body is left empty in the editor. This would match the behavior of Git for creating commits. I actually assumed this was the case at first and accidentally created a PR prematurely as there seems to be no way to abort the process after the editor has been opened for the body.
Yeah, this is something I've run into several times myself. Usually I have to close the terminal window to cancel it. Not ideal! I've been thinking about how to solve this for a while. We can't just abort when the body is empty (like what git does), since an empty body is valid. Maybe abort on an empty body, and have a --no-body flag? Or, as you said, a confirmation dialogue.
Generally, the UI could be more interactive. We could, for example, make the TITLE argument optional and ask the user if it isn't provided.
I've wanted to add options for more interactivity for a while now, but have had no idea how to go about it. I'd like it to be an option to toggle, since I personally prefer non-interactive interfaces. I do have some concern over the maintainability of designing for both options.
As part of working on #227, I had the idea of including the title in the front matter when editing the body. Setting the title via the command line doesn't really allow for supporting the title field of templates, whereas that could. Having a front matter, that'd also make it possible to disambiguate an empty body and aborting the PR.
It seems like we already make some attempt to guess a title, because instead of a normal arg parsing error, I got this when I left it out: [...]
title is optional already because it isn't set when using the --web option
Another point I'd like to improve is creating a PR from a fork. Currently PRs are created on the fork itself, but in 90% of cases (citation needed, but somewhere around there), that isn't actually what you want to do. Creating a PR on the upstream repo requires setting --base ^, which I can confirm from personal experience is easy to forget and/or mess up. I think it would be better if it defaulted to the upstream repo, with a specific option for creating it on the fork.
> If the PR consists of only one commit, we should default the title of the PR to the commit message and the body of the PR to further lines of the commit text (if any). The web UI does this too. In fact, I'm not quite sure what it does for PRs with multiple commits. I added this in !223, though it isn't the default, it requires setting the flag. It also doesn't work with AGit yet, but I have looked some into how to do that. That fills in the commit body by default when opening the editor too, even without the flag set. > Before creating the PR, print out information about the PR we're about to create and ask the user to confirm. I had thought of printing out the PR in the same style as fj pr view after it was created, but a confirmation dialogue there is also interesting... > We should especially do this if the PR body is left empty in the editor. This would match the behavior of Git for creating commits. I actually assumed this was the case at first and accidentally created a PR prematurely as there seems to be no way to abort the process after the editor has been opened for the body. Yeah, this is something I've run into several times myself. Usually I have to close the terminal window to cancel it. Not ideal! I've been thinking about how to solve this for a while. We can't just abort when the body is empty (like what git does), since an empty body is valid. Maybe abort on an empty body, and have a --no-body flag? Or, as you said, a confirmation dialogue. > Generally, the UI could be more interactive. We could, for example, make the TITLE argument optional and ask the user if it isn't provided. I've wanted to add options for more interactivity for a while now, but have had no idea how to go about it. I'd like it to be an option to toggle, since I personally prefer non-interactive interfaces. I do have some concern over the maintainability of designing for both options. As part of working on #227, I had the idea of including the title in the front matter when editing the body. Setting the title via the command line doesn't really allow for supporting the title field of templates, whereas that could. Having a front matter, that'd also make it possible to disambiguate an empty body and aborting the PR. > It seems like we already make some attempt to guess a title, because instead of a normal arg parsing error, I got this when I left it out: [...] title is optional already because it isn't set when using the --web option --- Another point I'd like to improve is creating a PR from a fork. Currently PRs are created on the fork itself, but in 90% of cases (citation needed, but somewhere around there), that isn't actually what you want to do. Creating a PR on the upstream repo requires setting --base ^, which I can confirm from personal experience is easy to forget and/or mess up. I think it would be better if it defaulted to the upstream repo, with a specific option for creating it on the fork.
Cyborus added the Kind/Design label 2025-12-03 23:02:07 +01:00
Cyborus added this to the v0.4.0 milestone 2025-12-03 23:11:35 +01:00
LordMZTE referenced this issue 2026-01-10 19:35:21 +01:00 feat: issue & pr templates #261
LordMZTE commented 2026-01-10 19:36:20 +01:00
Author
Collaborator
Copy link
As already mentioned in code review on #261, we should also take into account suggested titles for PR/issue templates.
As already mentioned in code review on #261, we should also take into account suggested titles for PR/issue templates.
👍 1
Cyborus commented 2026-01-11 17:07:14 +01:00
Member
Copy link
I don't think I will have time to do this before v0.4.0. If you think you do, feel free, otherwise I'm gonna remove this from the v0.4.0 milestone
I don't think I will have time to do this before v0.4.0. If you think you do, feel free, otherwise I'm gonna remove this from the v0.4.0 milestone
LordMZTE commented 2026-01-11 21:34:17 +01:00
Author
Collaborator
Copy link
I don't think I will either, let's postpone this.
I don't think I will either, let's postpone this.
Cyborus removed this from the v0.4.0 milestone 2026-01-11 21:47:36 +01:00
stalecontext referenced this issue from stalecontext/forgejo-cli-plus 2026-03-18 06:43:48 +01:00 Agentic CLI: --yes, --verbose, --force, --dry-run flags #22
stalecontext referenced this issue from a commit 2026-03-18 06:45:25 +01:00 Agentic CLI: --yes, --verbose, --force, --dry-run flags (#22)
ncf referenced this issue 2026-04-25 23:30:08 +02:00 Error: config value 'branch.channel-space.remote' was not found #398
Sign in to join this conversation.
No Branch/Tag specified
main
renovate/lock-file-maintenance
renovate/serde-saphyr-0.x
docs/contributing
no-port-in-refspec
login/v16.next.forgejo.org
crates-io-publish
0.5.x
compile-time-fluent
0.4.x
localization-alias-demo
api_url_field
v0.5.0
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.1.1
v0.1.0
v0.0.4
v0.0.3
v0.0.2
v0.0.1
Labels
Clear labels[ Kind/Breaking Breaking change that won't be backward compatible
](#)[ Kind/Bug Something is not working
](#)[ Kind/Design Discussion about UI/UX design
](#)[ Kind/Documentation Documentation changes
](#)[ Kind/Enhancement Improve existing functionality
](#)[ Kind/Feature New functionality
](#)[ Kind/Security This is security issue
](#)[ Kind/Testing Issue or pull request related to testing
](#)[ Kind/Upstream This is an issue with upstream software (Forgejo) that is probably not our fault
](#)
[ Priority
Critical The priority is critical
](#)[ Priority
High The priority is high
](#)[ Priority
Low The priority is low
](#)[ Priority
Medium The priority is medium
](#)
[ Reviewed
Confirmed Issue has been confirmed
](#)[ Reviewed
Duplicate This issue or pull request already exists
](#)[ Reviewed
Invalid Invalid issue
](#)[ Reviewed
Won't Fix This issue won't be fixed
](#)
[ Status
Abandoned Somebody has started to work on this but abandoned work
](#)[ Status
Blocked Something is blocking this issue or pull request
](#)[ Status
Need More Info Feedback is required to reproduce issue or to continue work
](#)
[ Suspicious
](#)
No labels Kind/Breaking Kind/Bug Kind/Design Kind/Documentation Kind/Enhancement Kind/Feature Kind/Security Kind/Testing Kind/Upstream [ Priority
Critical ](/forgejo-contrib/forgejo-cli/issues?labels=173012) [ Priority
High ](/forgejo-contrib/forgejo-cli/issues?labels=173013) [ Priority
Low ](/forgejo-contrib/forgejo-cli/issues?labels=173015) [ Priority
Medium ](/forgejo-contrib/forgejo-cli/issues?labels=173014) [ Reviewed
Confirmed ](/forgejo-contrib/forgejo-cli/issues?labels=173007) [ Reviewed
Duplicate ](/forgejo-contrib/forgejo-cli/issues?labels=173005) [ Reviewed
Invalid ](/forgejo-contrib/forgejo-cli/issues?labels=173006) [ Reviewed
Won't Fix ](/forgejo-contrib/forgejo-cli/issues?labels=173008) [ Status
Abandoned ](/forgejo-contrib/forgejo-cli/issues?labels=173011) [ Status
Blocked ](/forgejo-contrib/forgejo-cli/issues?labels=173010) [ Status
Need More Info ](/forgejo-contrib/forgejo-cli/issues?labels=173009) Suspicious
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
Notifications Subscribe
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
No due date set.
Dependencies
No dependencies set.
Reference
forgejo-contrib/forgejo-cli#244
WritePreview
Loading…
Add table
| Rows | | | Columns | |
CancelOK
Add a link
Url Description Hint: With a URL in your clipboard, you can paste directly into the editor to create a link.
CancelOK
CancelSave
Reference in a new issue
Repository
forgejo-contrib/forgejo-cli
Title
Body
Create issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
No Yes