Comment association should work on the hunk, not the line, level #5947

New Issue

GiteaMirror · 2025-11-02T06:41:01-06:00

GiteaMirror commented

2025-11-02 06:41:01 -06:00

Originally created by @saagarjha on GitHub (Sep 4, 2020).

Gitea version (or commit ref): 1.13.0+dev-434-gdcb543ac2
Git version: 2.17.1
Operating system: Ubuntu 18.04.5 LTS
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL): https://try.gitea.io/saagarjha/review-comment-shift/pulls/1
- No
- Not relevant
Log gist:

Description

Gitea seems to associate review comments to a commit and a line number, however, this does not really play well with people adding commits that modify the code that the commits point to. For example, it will mark something as "outdated" if it is merely shifted around in such a way that that line shows up as modified, even though there has been no logical change the the line that it tracks. Depending on the situation, sometimes it will not detect a change but the comment will not move along with other changes in the file–if I make a comment at line 50 and then line 30 gets deleted in a subsequent commit, sometimes it will still show the comment at line 50 even though it "should" now be at line 49.

Screenshots

The comment has completely disappeared from here:

and is "Outdated" here:

even though logically I haven't actually touched those lines.

Originally created by @saagarjha on GitHub (Sep 4, 2020).   - Gitea version (or commit ref): 1.13.0+dev-434-gdcb543ac2 - Git version: 2.17.1 - Operating system: Ubuntu 18.04.5 LTS - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [X] SQLite - Can you reproduce the bug at https://try.gitea.io: - [X] Yes (provide example URL): https://try.gitea.io/saagarjha/review-comment-shift/pulls/1 - [ ] No - [ ] Not relevant - Log gist: ## Description Gitea seems to associate review comments to a commit and a line number, however, this does not really play well with people adding commits that modify the code that the commits point to. For example, it will mark something as "outdated" if it is merely shifted around in such a way that that line shows up as modified, even though there has been no logical change the the line that it tracks. Depending on the situation, sometimes it will not detect a change but the comment will not move along with other changes in the file–if I make a comment at line 50 and then line 30 gets deleted in a subsequent commit, sometimes it will still show the comment at line 50 even though it "should" now be at line 49. ## Screenshots The comment has completely disappeared from here: <img width="1171" alt="Screen Shot 2020-09-04 at 16 49 01" src="https://user-images.githubusercontent.com/13786931/92291658-89c0a980-eece-11ea-8ca1-0612de7333da.png"> and is "Outdated" here: <img width="816" alt="Screen Shot 2020-09-04 at 16 49 25" src="https://user-images.githubusercontent.com/13786931/92291676-98a75c00-eece-11ea-8496-7223b43cb23c.png"> even though logically I haven't actually touched those lines.

GiteaMirror added the issue/needs-feedback type/bug labels 2025-11-02 06:41:01 -06:00

GiteaMirror closed this issue

2025-11-02 06:41:02 -06:00

GiteaMirror commented

2025-11-02 06:41:02 -06:00

@zeripath commented on GitHub (Sep 5, 2020):

Comment invalidation is done by:

dba5d82f86/models/issue_comment.go (L575-L590)

This uses the more simplistic route of checking if the line referenced in the comment has changed. To do something better likely would require us to try to match the .Patch (the hunk you refer to) if the simple method fails, but what we don't want is that the comment ends up matching similar code 4 lines down.

@zeripath commented on GitHub (Sep 5, 2020): Comment invalidation is done by: https://github.com/go-gitea/gitea/blob/dba5d82f86dc9dc757404f03bf80ebbe28a5a0b1/models/issue_comment.go#L575-L590 This uses the more simplistic route of checking if the line referenced in the comment has changed. To do something better likely would require us to try to match the .Patch (the hunk you refer to) if the simple method fails, but what we don't want is that the comment ends up matching similar code 4 lines down.

GiteaMirror commented

2025-11-02 06:41:02 -06:00

@Limegrass commented on GitHub (Dec 24, 2020):

I haven't dove into the code, so forgive me for speaking without much information, but what would an acceptable invalidation method look like?

For example, would some edit distance + line number/patch difference heuristic be an acceptable measure to rank how to best match the lines? I'm just assuming it's possible to access the different patch versions from the invalidation function though.

Just trying to get a sense of what type of PR would be acceptable if someone wanted to implement it, if hunk matching is not ideal.

@Limegrass commented on GitHub (Dec 24, 2020): I haven't dove into the code, so forgive me for speaking without much information, but what would an acceptable invalidation method look like? For example, would some edit distance + line number/patch difference heuristic be an acceptable measure to rank how to best match the lines? I'm just assuming it's possible to access the different patch versions from the invalidation function though. Just trying to get a sense of what type of PR would be acceptable if someone wanted to implement it, if hunk matching is not ideal.

GiteaMirror commented

2025-11-02 06:41:03 -06:00

@lunny commented on GitHub (May 14, 2023):

Is this still a problem?

@lunny commented on GitHub (May 14, 2023): Is this still a problem?

GiteaMirror commented

2025-11-02 06:41:03 -06:00

@saagarjha commented on GitHub (May 18, 2023):

I haven’t used Gita for a while, so I wouldn’t know, unfortunately. Maybe you can mark this as inactive and reprioritize it if someone else comes along with similar feedback?

@saagarjha commented on GitHub (May 18, 2023): I haven’t used Gita for a while, so I wouldn’t know, unfortunately. Maybe you can mark this as inactive and reprioritize it if someone else comes along with similar feedback?

GiteaMirror commented

2025-11-02 06:41:03 -06:00

@GiteaBot commented on GitHub (Sep 8, 2023):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Sep 8, 2023): We close issues that need feedback from the author if there were no new comments for a month. :tea:

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#5947