Gitea: Pull request features #13

New Issue

Brecht Van Lommel · 2023-02-08T13:37:20+01:00

Brecht Van Lommel commented

2023-02-08 13:37:20 +01:00

High Priority

Medium Priority

Disable disables large teams as reviewers, can accidentally mail notify people then (workaround in our fork)
Allow edits by maintainers as default (as it is on GitHub). Allows reviewers to merge/rebase and start build to verify things work with latest main. (upstream pull)
Avoid using @noreply.localhost email for squash merges (#41, upstream pull)
Filter reviews where you're a reviewer, but not review requested (upstream pull)
Pull request filters (as part of Type but not home page?): no reviewer, waiting review, changes requested, approved

Low Priority

Hide branches in pull requests list. Adds a lot of visual noise and seems like a detail. (solved in theme but might be worth proposing upstream)
Enable Manually Merged once it's fixed (upstream pull)
Use full pull request URL in merge message template
When typing an inline comment on a PR, ctrl+enter will submit as a comment, even though the "start review" button is highlighted as default button. "Start review" is also the desired default for ctrl+enter.
Ability for anyone with commit / PR write access to remove reviewers (can only add now)
Only repo owners can used Manually merged, let anyone with write access do it
Resolving conversations only collapses a single comment
Allow requesting changes without leaving a comment, often a comment was already written in the conversation view
Email notification for pull requests is not distinguishable from issue for email filtering (at least not without inspecting email headers which e.g. Gmail can't do)
Show commit status for force pushes
Changing the target branch in a pull requests causes commits list to be updated, but not files changed.
Show number of characters per line in squash merge description editor like elsewhere. Or even better, have the line wrap be configurable per repo and enforced.
Can only comment on a single line of code, not multiple
Blocking reviewers (not amount, but particular person)
Add PR # not only in last commit but all
Issue # in forked repo does not link to original repo
Set reviewers as part of submitting pull requests (it's confusing because you can set assignees which sounds like it will be reviewers)
Dynamically show correct command line instructions depending on chosen merge type (#42)
Show command line instructions for how to locally checkout pull, also for non-reviewers
Fork with only main branch (upstream)
Sync fork button in the UI
Review state is temporaly incorrect when viewing file and return to pull request. (#18)
Syntax highlighting does not work correctly across multiple lines, see for example multi line /* * / comments. (upstream #23176)

### High Priority ### Medium Priority - [x] Disable disables large teams as reviewers, can accidentally mail notify people then ([workaround in our fork](https://github.com/blender/gitea/tree/blender-avoid-large-team-mentions)) - [x] Allow edits by maintainers as default (as it is on GitHub). Allows reviewers to merge/rebase and start build to verify things work with latest main. ([upstream pull](https://github.com/go-gitea/gitea/pull/22862)) - [x] Avoid using @noreply.localhost email for squash merges (#41, [upstream pull](https://github.com/go-gitea/gitea/pull/22977)) - [x] Filter reviews where you're a reviewer, but not review requested ([upstream pull](https://github.com/go-gitea/gitea/pull/22927)) - [ ] Pull request filters (as part of Type but not home page?): no reviewer, waiting review, changes requested, approved ### Low Priority - [x] Hide branches in pull requests list. Adds a lot of visual noise and seems like a detail. (solved in theme but might be worth proposing upstream) - [x] Enable Manually Merged once it's fixed ([upstream pull](https://github.com/go-gitea/gitea/pull/23015)) - [x] Use full pull request URL in merge message template - [x] When typing an inline comment on a PR, ctrl+enter will submit as a comment, even though the "start review" button is highlighted as default button. "Start review" is also the desired default for ctrl+enter. - [ ] Ability for anyone with commit / PR write access to remove reviewers (can only add now) - [x] Only repo owners can used Manually merged, let anyone with write access do it - [x] Resolving conversations only collapses a single comment - [ ] Allow requesting changes without leaving a comment, often a comment was already written in the conversation view - [ ] Email notification for pull requests is not distinguishable from issue for email filtering (at least not without inspecting email headers which e.g. Gmail can't do) - [ ] Show commit status for force pushes - [x] Changing the target branch in a pull requests causes commits list to be updated, but not files changed. - [ ] Show number of characters per line in squash merge description editor like elsewhere. Or even better, have the line wrap be configurable per repo and enforced. - [ ] Can only comment on a single line of code, not multiple - [ ] Blocking reviewers (not amount, but particular person) - [ ] Add PR # not only in last commit but all - [ ] Issue # in forked repo does not link to original repo - [ ] Set reviewers as part of submitting pull requests (it's confusing because you can set assignees which sounds like it will be reviewers) - [x] Dynamically show correct command line instructions depending on chosen merge type (#42) - [x] Show command line instructions for how to locally checkout pull, also for non-reviewers - [x] Fork with only main branch ([upstream](https://github.com/go-gitea/gitea/pull/25821)) - [ ] Sync fork button in the UI - [ ] Review state is temporaly incorrect when viewing file and return to pull request. (#18) - [ ] Syntax highlighting does not work correctly across multiple lines, see for example multi line `/* * /` comments. ([upstream #23176](https://github.com/go-gitea/gitea/issues/23176))

👍 1

Brecht Van Lommel referenced this issue

2023-02-08 13:37:58 +01:00

Pull Request UI #6

Brecht Van Lommel added the

Service

Gitea

label 2023-02-08 16:54:39 +01:00

Brecht Van Lommel referenced this issue from blender/blender

2023-02-09 18:55:58 +01:00

UI: OS File Operations Within File Browser #104531

Brecht Van Lommel referenced this issue

2023-02-13 16:29:53 +01:00

Review state is temporaly incorrect when viewing file and return to pull request. #18

Brecht Van Lommel referenced this issue

2023-02-13 16:32:35 +01:00

inconsistencies in git-hash-based links between organizations #25

Brecht Van Lommel referenced this issue

2023-02-15 11:27:28 +01:00

Pull Request: File-Tree sidebar is too small for long filenames #35

Brecht Van Lommel referenced this issue

2023-02-18 15:19:54 +01:00

Same command line instructions for "Rebase then fast-forward" and "Create squash commit" #42

Brecht Van Lommel changed title from ~~Pull Request Features~~ to Pull request features

2023-03-09 23:59:16 +01:00

Bart van der Braak added this to the DevOps Progress Board project 2024-07-16 12:59:17 +02:00

Bart van der Braak changed title from ~~Pull request features~~ to Gitea: Pull request features

2024-07-17 15:18:33 +02:00

Bart van der Braak added the

Type

Feature

label 2024-08-01 11:27:56 +02:00

Bart van der Braak closed this issue

2024-08-14 10:31:10 +02:00

Bart van der Braak reopened this issue

2024-08-14 10:35:31 +02:00

Richard Antalik commented

2024-10-04 15:37:08 +02:00

I have found some issues that could be worth resolving:

If you add comment with text like better would be to resolve #109943 in PR it will automatically close the mentioned issue when PR lands. This is without any warning.
You can not stage responses to inline comments resulting in huge noise in email notifications
When you mark something as resolved, next/prev button is hidden so navigation is harder
When you mark something as resolved, responses are hidden by default and this could be comment to inline posted month ago.

I have found some issues that could be worth resolving: - If you add comment with text like `better would be to resolve #109943` in PR it will automatically close the mentioned issue when PR lands. This is without any warning. - You can not stage responses to inline comments resulting in huge noise in email notifications - When you mark something as resolved, next/prev button is hidden so navigation is harder - When you mark something as resolved, responses are hidden by default and this could be comment to inline posted month ago.

Sign in to join this conversation.