-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements to content history #17746
Conversation
jpraet
commented
Nov 21, 2021
- initialize content history when making an edit to an old item created before the introduction of content history (Comment history is loading slowly + has an offByOne error #17676)
- also show edit history for code comments on files tab of pull request
* initialize content history when making an edit to an old item created before the introduction of content history * show edit history for code comments on pull request files tab
Should I remove these calls that eagerly initialize the content history when creating a new issue / pr / comment? Lines 1015 to 1018 in d710af6
gitea/services/comments/comments.go Lines 28 to 31 in c5c88f2
|
@@ -42,11 +42,26 @@ func CreateIssueComment(doer *models.User, repo *models.Repository, issue *model | |||
|
|||
// UpdateComment updates information of comment. | |||
func UpdateComment(c *models.Comment, doer *models.User, oldContent string) error { | |||
var needsContentHistory = c.Content != oldContent && | |||
(c.Type == models.CommentTypeComment || c.Type == models.CommentTypeReview || c.Type == models.CommentTypeCode) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have content history for "pending" code comments on non-submitted review? GitHub doesn't do that either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't thought about it. For a simple idea, if the logic is not complex then we can have it, but if we need to pay much effect to follow the GitHub behavior, well, it depends 😂. Both are fine to me.
Fix a flaw in keepLimitedContentHistory, the first and the last should never be deleted
I also added a patch to fix a flaw (I was going to fix it, but since we have this PR, so I think it's good to have it now 😊) |
Yep, I think we can remove them, then an issue without editing won't have history data, it would save some storage space. |
Tested on my side and LGTM. |
Codecov Report
@@ Coverage Diff @@
## main #17746 +/- ##
=======================================
Coverage ? 45.54%
=======================================
Files ? 807
Lines ? 89885
Branches ? 0
=======================================
Hits ? 40936
Misses ? 42400
Partials ? 6549
Continue to review full report at Codecov.
|
CommentID: commentID, | ||
}) | ||
if err != nil { | ||
log.Error("can not fetch issue content history. err=%v", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just return the error but add a special log here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it just follows my first PR, a personal preference for error handling.
Usually I would like to report important errors as early as possible.
Otherwise:
- The error may be ignored be callers
- The caller prints the error with a unrelated stacktrace (especially in Go, the errors don't have stacktrace)
* Improvements to content history * initialize content history when making an edit to an old item created before the introduction of content history * show edit history for code comments on pull request files tab * Fix a flaw in keepLimitedContentHistory Fix a flaw in keepLimitedContentHistory, the first and the last should never be deleted * Remove obsolete eager initialization of content history