Add option to post comments while watching commit difference #13116

New Issue

GiteaMirror · 2025-11-02T10:31:36-06:00

GiteaMirror commented

2025-11-02 10:31:36 -06:00

Originally created by @dev1way on GitHub (Jun 7, 2024).

Feature Description

I cannot add any comments while watching commit diffrence in merge request.

I must open all changes to get this functionality available.

Please, add this feautre ASAP <3

Screenshots

Originally created by @dev1way on GitHub (Jun 7, 2024). ### Feature Description I cannot add any comments while watching commit diffrence in merge request. I must open all changes to get this functionality available. Please, add this feautre ASAP <3 ### Screenshots ![image](https://github.com/go-gitea/gitea/assets/25363842/845972a3-8830-44b4-95c2-02c66d7d8e3a)

GiteaMirror added the type/proposal label 2025-11-02 10:31:36 -06:00

GiteaMirror commented

2025-11-02 10:31:37 -06:00

@Volkoks commented on GitHub (Jun 7, 2024):

Yes, there is a problem. It must be fixed)

@Volkoks commented on GitHub (Jun 7, 2024): Yes, there is a problem. It must be fixed)

GiteaMirror commented

2025-11-02 10:31:37 -06:00

@delvh commented on GitHub (Jun 7, 2024):

while watching commit difference

Wait, am I understanding you correctly that you selected a commit range and tried to review the PR on that?
If yes, I'd say that it is disabled intentionally:
If you review a commit range, the PR will have diverged compared to the state you reviewed.
So, how are you supposed to give an accurate, non-outdated review?
There's one aspect to this I don't think we currently implement:
When the commit range includes the latest commit, this reasoning becomes invalid, so there it can be enabled.

Apart from that, I am against changing the behavior here (assuming I understood your request correctly) as the number of people who will deliberately use this behavior is significantly smaller than the number of people who will trip over it and thus post invalid reviews.

@delvh commented on GitHub (Jun 7, 2024): > while watching commit difference Wait, am I understanding you correctly that you selected a commit range and tried to review the PR on that? If yes, I'd say that it is disabled intentionally: If you review a commit range, the PR will have diverged compared to the state you reviewed. So, how are you supposed to give an accurate, non-outdated review? There's one aspect to this I don't think we currently implement: When the commit range includes the latest commit, this reasoning becomes invalid, so there it can be enabled. Apart from that, I am against changing the behavior here (assuming I understood your request correctly) as the number of people who will deliberately use this behavior is significantly smaller than the number of people who will trip over it and thus post invalid reviews.

GiteaMirror commented

2025-11-02 10:31:37 -06:00

@dev1way commented on GitHub (Aug 6, 2024):

I understand you, thanks.

I have PRs with big amount of changes, and review only one commit will significantly help to review faster.
If there is no any option to approve or request changes, may be there is any availability to add comments to commit?

@dev1way commented on GitHub (Aug 6, 2024): I understand you, thanks. I have PRs with big amount of changes, and review only one commit will significantly help to review faster. If there is no any option to approve or request changes, may be there is any availability to add comments to commit?

GiteaMirror commented

2025-11-02 10:31:37 -06:00

@dev1way commented on GitHub (Aug 9, 2024):

Also, in case of large PR, it will be cool to review it through commits, where logic is separated

@dev1way commented on GitHub (Aug 9, 2024): Also, in case of large PR, it will be cool to review it through commits, where logic is separated

GiteaMirror commented

2025-11-02 10:31:37 -06:00

@dev1way commented on GitHub (Jun 9, 2025):

When a reviewer adds a comment to the outdated code, this comment should be automatically marked as "Outdated". And its okay.

If we have a large MR with 40+ changed files, there is hard to review this MR again, after pushing bunch of refactoring (from code review)
In this case, leaving comments only in a commit range is very helpfull.

Despite the fact that reviewer can mark files as "Viewed", which can help and boost the review, the problem is still here.
If the file is large and diff is large too, after fixes from review the changes are lost in a huge bunch of diff.

@dev1way commented on GitHub (Jun 9, 2025): When a reviewer adds a comment to the outdated code, this comment should be automatically marked as "Outdated". And its okay. If we have a large MR with 40+ changed files, there is hard to review this MR again, after pushing bunch of refactoring (from code review) In this case, leaving comments only in a commit range is very helpfull. Despite the fact that reviewer can mark files as "Viewed", which can help and boost the review, the problem is still here. If the file is large and diff is large too, after fixes from review the changes are lost in a huge bunch of diff.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13116