Add inline comments on commits #2313

@techknowlogick commented on GitHub (Sep 21, 2018):

@LukeOwlclaw this issue is inline comments on commits. Inline comments on code in PRs already (per the docs you linked). also please take this comment same way, I'm a bit sleepy due to jetlag so I apologize if this response doesn't come off as friendly (I tried to make it friendly).

@techknowlogick commented on GitHub (Sep 21, 2018): @LukeOwlclaw this issue is inline comments on commits. Inline comments on code in PRs already (per the docs you linked). also please take this comment same way, I'm a bit sleepy due to jetlag so I apologize if this response doesn't come off as friendly (I tried to make it friendly).

GiteaMirror commented

@rakshith-ravi commented on GitHub (Nov 22, 2018):

@xxxtonixxx is there a PR that currently addresses this?

@rakshith-ravi commented on GitHub (Nov 22, 2018): @xxxtonixxx is there a PR that currently addresses this?

GiteaMirror commented

@tonivj5 commented on GitHub (Nov 22, 2018):

I think no 😢

@tonivj5 commented on GitHub (Nov 22, 2018): I think no :cry:

GiteaMirror commented

2025-11-02 04:32:23 -06:00

@rakshith-ravi commented on GitHub (Dec 30, 2018):

@techknowlogick I know open source projects hate asking for ETAs, and I really don't want to come off as rude, but I'm just curious how high on the priority list is this in? There doesn't seem to be a milestone listed, so what are the odds that we'll see this implemented in 1.7.x? Is this something the team is actively planning to work on or is it deferred for sometime later? Just curious so that I can set my expectations clear 😅

@rakshith-ravi commented on GitHub (Dec 30, 2018): @techknowlogick I know open source projects hate asking for ETAs, and I really don't want to come off as rude, but I'm just curious how high on the priority list is this in? There doesn't seem to be a milestone listed, so what are the odds that we'll see this implemented in 1.7.x? Is this something the team is actively planning to work on or is it deferred for sometime later? Just curious so that I can set my expectations clear 😅

GiteaMirror commented

@techknowlogick commented on GitHub (Dec 30, 2018):

@rakshith-ravi sadly it won’t be in 1.7 as we are a in a feature freeze for that release, as for ETAs I cant say, as for the project we don’t have a roadmap and things are added to the project as PRs happen. That means even a non-team member could work on this, if you or someone you know has Holland skills. As a side note you don’t come off as rude and I really appreciate how you asked as it was really kind :)

@techknowlogick commented on GitHub (Dec 30, 2018): @rakshith-ravi sadly it won’t be in 1.7 as we are a in a feature freeze for that release, as for ETAs I cant say, as for the project we don’t have a roadmap and things are added to the project as PRs happen. That means even a non-team member could work on this, if you or someone you know has Holland skills. As a side note you don’t come off as rude and I really appreciate how you asked as it was really kind :)

GiteaMirror commented

2025-11-02 04:32:23 -06:00

@stale[bot] commented on GitHub (Feb 28, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 28, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:32:24 -06:00

@tonivj5 commented on GitHub (Feb 28, 2019):

Not yet, please 😢

@tonivj5 commented on GitHub (Feb 28, 2019): Not yet, please :cry:

GiteaMirror commented

2025-11-02 04:32:24 -06:00

@ghost commented on GitHub (Mar 31, 2019):

Yeah this would be fantastic!

@ghost commented on GitHub (Mar 31, 2019): Yeah this would be fantastic!

GiteaMirror commented

2025-11-02 04:32:24 -06:00

@6543 commented on GitHub (Jun 15, 2019):

Vote

@6543 commented on GitHub (Jun 15, 2019): Vote

GiteaMirror commented

@lunny commented on GitHub (Jun 16, 2019):

So If we can comment on any commit. We should consider some implementation things below:

Where should the comments stored, currently all comments stored with an issue(pr)
We have to notify all related users(who?) via UI/mail and etc.

@lunny commented on GitHub (Jun 16, 2019): So If we can comment on any commit. We should consider some implementation things below: 1) Where should the comments stored, currently all comments stored with an issue(pr) 2) We have to notify all related users(who?) via UI/mail and etc.

GiteaMirror commented

@rakshith-ravi commented on GitHub (Jun 16, 2019):

I'd recommend a structure like this -
There would be two different kinds of comment on commits: One on the upstream code and one on the PR.

Both the comment on commit can be linked to the repo (the repo ID as the primary key). That way, Even when the PR gets merged, the comment still stays. We could use a composite key of the commit hash and the repo ID as the primary key.
As for the notification, we could perhaps notify all the users who are contributors of the repo. If it's a PR, I guess the PR owner will also be notified.

If I knew GoLang better, I would've implemented this myself. Unfortunately, I can only contribute in terms of software architecture

@rakshith-ravi commented on GitHub (Jun 16, 2019): I'd recommend a structure like this - There would be two different kinds of comment on commits: One on the upstream code and one on the PR. - Both the comment on commit can be linked to the repo (the repo ID as the primary key). That way, Even when the PR gets merged, the comment still stays. We could use a composite key of the commit hash and the repo ID as the primary key. - As for the notification, we could perhaps notify all the users who are contributors of the repo. If it's a PR, I guess the PR owner will also be notified. If I knew GoLang better, I would've implemented this myself. Unfortunately, I can only contribute in terms of software architecture

GiteaMirror commented

@zeripath commented on GitHub (Jun 16, 2019):

I suspect we should leverage git notes or git notes-like behaviour for this. I suspect that putting this in to the database is only going to cause trouble. I wonder if the comments on PRs should do the same.

@zeripath commented on GitHub (Jun 16, 2019): I suspect we should leverage git notes or git notes-like behaviour for this. I suspect that putting this in to the database is only going to cause trouble. I wonder if the comments on PRs should do the same.

GiteaMirror commented

@zeripath commented on GitHub (Jun 16, 2019):

@rakshith-ravi If you can program in an imperative language you can program in go. It's really not a very difficult language if you can get past its idiosyncrasies.

@zeripath commented on GitHub (Jun 16, 2019): @rakshith-ravi If you can program in an imperative language you can program in go. It's really not a very difficult language if you can get past its idiosyncrasies.

GiteaMirror commented

@lunny commented on GitHub (Jun 16, 2019):

PR comments have been implemented. I think we are talking about commit comment without a PR.

@lunny commented on GitHub (Jun 16, 2019): PR comments have been implemented. I think we are talking about commit comment without a PR.

GiteaMirror commented

2025-11-02 04:32:26 -06:00

@BaxAndrei commented on GitHub (Nov 23, 2019):

Yes, like on github

@BaxAndrei commented on GitHub (Nov 23, 2019): Yes, like on github ![image](https://user-images.githubusercontent.com/12484505/69641411-d4bcaf00-1068-11ea-8d79-d8bc4cb0f72c.png) ![image](https://user-images.githubusercontent.com/12484505/69475312-3d3f2e00-0dd4-11ea-8213-227f5c952046.png)

GiteaMirror commented

@0x416c69 commented on GitHub (Nov 26, 2019):

Vote.

Gitea really lacks this important feature. Everything else I could live on without but not this.

@0x416c69 commented on GitHub (Nov 26, 2019): Vote. Gitea really lacks this important feature. Everything else I could live on without but not this.

GiteaMirror commented

2025-11-02 04:32:26 -06:00

@guillep2k commented on GitHub (Nov 26, 2019):

@0x416c69 Just so I understand your use case, why comments are so important in a specific commit? I've seen GitHub has that, but I never could picture a proper scenario for this. Commits get quickly lost in the sea of blobs....

@guillep2k commented on GitHub (Nov 26, 2019): @0x416c69 Just so I understand your use case, why comments are so important in a specific commit? I've seen GitHub has that, but I never could picture a proper scenario for this. Commits get quickly lost in the sea of blobs....

GiteaMirror commented

2025-11-02 04:32:26 -06:00

@BaxAndrei commented on GitHub (Nov 26, 2019):

I use this function. Especially to signal to the people who sent the commit that something is wrong, exempting me from opening an issue. It is also useful if I want to add something extra to that commit or mention something.

@BaxAndrei commented on GitHub (Nov 26, 2019): I use this function. Especially to signal to the people who sent the commit that something is wrong, exempting me from opening an issue. It is also useful if I want to add something extra to that commit or mention something.

GiteaMirror commented

@lunny commented on GitHub (Nov 26, 2019):

We also need refactor notification system to notify via ui/mail/webhook and etc.

@lunny commented on GitHub (Nov 26, 2019): We also need refactor notification system to notify via ui/mail/webhook and etc.

GiteaMirror commented

@0x416c69 commented on GitHub (Nov 27, 2019):

@guillep2k Best way possible for me to talk about a certain commit is the commit comment. Although I could just stick with a messenger and a group talk, place the commit link/hash and talk about it there with my team but it will get really messy and the track of the conversation will be lost very quickly.

As a basic and common user of git, this I think is the most needed feature.

@0x416c69 commented on GitHub (Nov 27, 2019): @guillep2k Best way possible for me to talk about a certain commit is the commit comment. Although I could just stick with a messenger and a group talk, place the commit link/hash and talk about it there with my team but it will get really messy and the track of the conversation will be lost very quickly. As a _basic and common_ user of git, this I think is the most needed feature.

GiteaMirror commented

@jcfigueiredo commented on GitHub (Jan 8, 2020):

@0x416c69 Just so I understand your use case, why comments are so important in a specific commit? I've seen GitHub has that, but I never could picture a proper scenario for this. Commits get quickly lost in the see of blobs....

We use it a lot for code reviewing PRs before merging to master.

2ȼ

@jcfigueiredo commented on GitHub (Jan 8, 2020): > @0x416c69 Just so I understand your use case, why comments are so important in a specific commit? I've seen GitHub has that, but I never could picture a proper scenario for this. Commits get quickly lost in the see of blobs.... We use it a lot for code reviewing PRs before merging to master. - 2ȼ

GiteaMirror commented

@techknowlogick commented on GitHub (Jan 8, 2020):

@jcfigueiredo the review functionality already exists in PRs where you can comment on lines of code.

@techknowlogick commented on GitHub (Jan 8, 2020): @jcfigueiredo the review functionality already exists in PRs where you can comment on lines of code.

GiteaMirror commented

@Albirew commented on GitHub (Jan 8, 2020):

this "may" also be useful to reference a commit or part of it to an issue without touching issue itself (examples: "may make issue #1 reappear", "this exact part breaks PR !2", etc.) or discussing about a specific part of code.

Again, these can already be done the other way around (eg:"commit b822518e39 may make this issue reappear", "the changes on modules/setting/queue.go lines 58-59 of commit c779ac12c9 breaks this PR", etc.)

@Albirew commented on GitHub (Jan 8, 2020): this "may" also be useful to reference a commit or part of it to an issue without touching issue itself (examples: "_may make issue #1 reappear_", "_this exact part breaks PR !2_", etc.) or discussing about a specific part of code. Again, these can already be done the other way around (eg:"_commit b822518e396a569b89aab6d621b01eefe723caa7 may make this issue reappear_", "_the changes on modules/setting/queue.go lines 58-59 of commit c779ac12c971a4347d085f8dbca7531faab16221 breaks this PR_", etc.)

GiteaMirror commented

@gerdemann commented on GitHub (Jan 15, 2020):

This is an important feature for us. Is there anything we can do to get the feature?
Maybe a sponsorship would help?

@gerdemann commented on GitHub (Jan 15, 2020): This is an important feature for us. Is there anything we can do to get the feature? Maybe a sponsorship would help?

GiteaMirror commented

@findsynonyms commented on GitHub (Feb 23, 2020):

It is a useful feature.

@findsynonyms commented on GitHub (Feb 23, 2020): It is a useful feature.

GiteaMirror commented

@AllTaken commented on GitHub (May 1, 2020):

Yeah, this would make code reviews much easier for us.

We do "atomic" commits, as part of our workflow, meaning that each commit is easy to review by itself, but a pull request can be quite large and not so easy to review as a whole.

It is also much easier to review each commit with its commit message.

@AllTaken commented on GitHub (May 1, 2020): Yeah, this would make code reviews much easier for us. We do "atomic" commits, as part of our workflow, meaning that each commit is easy to review by itself, but a pull request can be quite large and not so easy to review as a whole. It is also much easier to review each commit with its commit message.

GiteaMirror commented

@cknoll commented on GitHub (May 31, 2020):

To add another use case: education.

Students create and maintain their code in a repo and the supervisor wants to comment on specific lines of code. Usually their is no workflow with pull requests.

To be honest for real applicability in education it should be easily possible to comment on every line of every file, not just the lines which changed in the respective commit. Reason: students which just have started using git, often do not have a good commit practice (complicated commit order, frequent changes on the same lines, bad commit messages). Commenting on the cumulated state would be a lot easier.

It might worth to mention that the education system inevitably works as multiplicator: tools which are used by university students are likely to be used by the professionals they evolve after graduation.

@cknoll commented on GitHub (May 31, 2020): To add another use case: **education**. Students create and maintain their code in a repo and the supervisor wants to comment on specific lines of code. Usually their is no workflow with pull requests. To be honest for real applicability in education it should be _easily_ possible to comment on every line of every file, not just the lines which changed in the respective commit. Reason: students which just have started using git, often do not have a good commit practice (complicated commit order, frequent changes on the same lines, bad commit messages). Commenting on the cumulated state would be a lot easier. It might worth to mention that the education system inevitably works as multiplicator: tools which are used by university students are likely to be used by the professionals they evolve after graduation.

GiteaMirror commented

@kullarkert commented on GitHub (Mar 22, 2021):

Really hoping to get this feature. I have intern and I really want to comment her commits and give some tips etc. Right now my only option is to mirror gitea repository to gitlab/github and comment in there.

@kullarkert commented on GitHub (Mar 22, 2021): Really hoping to get this feature. I have intern and I really want to comment her commits and give some tips etc. Right now my only option is to mirror gitea repository to gitlab/github and comment in there.

GiteaMirror commented

@JLuc commented on GitHub (Mar 30, 2021):

Also please allow to search commit comments.
It would then be possible to comment with keywords as "todo_documentation" or "done_documentation" so the documentation people manage and organise their work together along as the code evolves. This would also help prepare the detailed release news (shorter and not so technical version of the release logs).

@JLuc commented on GitHub (Mar 30, 2021): Also please allow to search commit comments. It would then be possible to comment with keywords as "todo_documentation" or "done_documentation" so the documentation people manage and organise their work together along as the code evolves. This would also help prepare the detailed release news (shorter and not so technical version of the release logs).

GiteaMirror commented

@MOHHALIM commented on GitHub (Apr 26, 2022):

It's a great feature to have as I had to take action items and comments in another document then share it with collaborators. It will be an upgrade to our experience.
Thanks gitea's team and contributors ❤️

@MOHHALIM commented on GitHub (Apr 26, 2022): It's a great feature to have as I had to take action items and comments in another document then share it with collaborators. It will be an upgrade to our experience. Thanks gitea's team and contributors ❤️

GiteaMirror commented

@pinuke commented on GitHub (May 31, 2022):

Even for forgetful programmers, this would be a blessed feature. I swear there are more instances where I forget what a piece of code does than actual files of source code that I have written in my life.

I could potentially solve this by writing summaries over my own code.

@pinuke commented on GitHub (May 31, 2022): Even for forgetful programmers, this would be a blessed feature. I swear there are more instances where I forget what a piece of code does than actual files of source code that I have written in my life. I could potentially solve this by writing summaries over my own code.

GiteaMirror commented

@bryanpedini commented on GitHub (Jul 20, 2022):

@cknoll @ https://github.com/go-gitea/gitea/issues/4898#issuecomment-636442186

Students create and maintain their code in a repo and the supervisor wants to comment on specific lines of code. Usually their is no workflow with pull requests.

IMHO students should first learn how to use proper management of their resources (know what an issue is, why it's filed, its purpose, when to close an issue, PRs and everything related, etc), and then learn git and apply their git knowledge on top of what they're already familiar with workflow-wise.
Again, just my 2c, but for me it would be kinda like giving a pilot the training on how to control the joke of a plane without explaining the reference manual, the non-normal checklists in case a problem arise, not telling them about the "mayday mayday mayday" call (or the less common non-strictly-emergency "pan pan pan" call), etc etc...

First give the fundations, then build on top.

@bryanpedini commented on GitHub (Jul 20, 2022): @cknoll @ https://github.com/go-gitea/gitea/issues/4898#issuecomment-636442186 > Students create and maintain their code in a repo and the supervisor wants to comment on specific lines of code. Usually their is no workflow with pull requests. IMHO students should first learn how to use proper management of their resources (know what an issue is, why it's filed, its purpose, when to close an issue, PRs and everything related, etc), and **then** learn git and apply their git knowledge on top of what they're already familiar with workflow-wise. Again, just my 2c, but for me it would be kinda like giving a pilot the training on how to control the joke of a plane without explaining the reference manual, the non-normal checklists in case a problem arise, not telling them about the "mayday mayday mayday" call (or the less common non-strictly-emergency "pan pan pan" call), etc etc... First give the fundations, **then** build on top.

GiteaMirror commented

2025-11-02 04:32:30 -06:00

@biju-ps commented on GitHub (Aug 1, 2022):

+1 very useful feature

@biju-ps commented on GitHub (Aug 1, 2022): +1 very useful feature

GiteaMirror commented

@MOHHALIM commented on GitHub (Oct 19, 2022):

Hi Gitea's team and contributors ❤️,
Is this feature going to be available soon?

@MOHHALIM commented on GitHub (Oct 19, 2022): Hi Gitea's team and contributors ❤️, Is this feature going to be available soon?

GiteaMirror commented

2025-11-02 04:32:30 -06:00

@cknoll commented on GitHub (Oct 23, 2022):

@MOHHALIM As this is an Free Software Project: A more constructive question would be: What can we (as a community) do to get this feature implemented soon?

E.g. I just realized, that there is the possibility to support the work on open issues on bountysource: https://app.bountysource.com/teams/gitea

By searching for this issue here I accidentally created a new bounty:
https://app.bountysource.com/issues/63187881-add-inline-comments-on-commits (with currently one anonymous supporter, anonymously "promising" 50$ (probably this is some creation default and I have not figured out how I can change that). )

Also, there is the the possibility to sponsor this project (i.e. support in a not issue specific way).

@cknoll commented on GitHub (Oct 23, 2022): @MOHHALIM As this is an Free Software Project: A more constructive question would be: What can we (as a community) do to get this feature implemented soon? E.g. I just realized, that there is the possibility to support the work on open issues on bountysource: https://app.bountysource.com/teams/gitea By searching for this issue here I accidentally created a new bounty: https://app.bountysource.com/issues/63187881-add-inline-comments-on-commits (with currently one anonymous supporter, anonymously "promising" 50$ (probably this is some creation default and I have not figured out how I can change that). ) Also, there is the the possibility to sponsor this project (i.e. support in a not issue specific way).

GiteaMirror commented

2025-11-02 04:32:30 -06:00

@twisted-nematic57 commented on GitHub (Nov 5, 2022):

Like the LibreOffice folks say, "if you want a new feature you suggest it. Then either make it yourself or fund it".

@twisted-nematic57 commented on GitHub (Nov 5, 2022): Like the LibreOffice folks say, "if you want a new feature you suggest it. Then either make it yourself or fund it".

GiteaMirror commented

@pinuke commented on GitHub (Nov 6, 2022):

IMO, we're taking this GoFundMe thing too far. I get it. We all get it. Money doesn't grow on trees, but this is the open source community you guys are talking to. Money doesn't come from any of our pockets. This is the poor programmers club

GH issues is for contributors and users to work on features. Not electronically pan-handle each other.

Look I'm broke too, but this is just poorly representing the FOSS community (Emphasis on F OSS). The FOSS defacto standard for this is to just tell people "we're too broke to work on it right now," not "please give me money to do it"

@pinuke commented on GitHub (Nov 6, 2022): IMO, we're taking this GoFundMe thing too far. I get it. We all get it. Money doesn't grow on trees, but this is the open source community you guys are talking to. _Money doesn't come from any of **our** pockets._ This is the poor programmers club GH issues is for contributors and users to work on features. Not electronically pan-handle each other. Look I'm broke too, but this is just poorly representing the FOSS community (Emphasis on ***F*** OSS). The FOSS defacto standard for this is to just tell people "we're too broke to work on it right now," not "please give me money to do it"

GiteaMirror commented

@KaKi87 commented on GitHub (Nov 6, 2022):

Actually, Gitea is now a for-profit company, most likely not broke and less free (as in freedom).

@KaKi87 commented on GitHub (Nov 6, 2022): Actually, Gitea is now a for-profit company, most likely not broke and less free (as in freedom).

GiteaMirror commented

@pinuke commented on GitHub (Nov 6, 2022):

@KaKi87 That just makes it so much worse.

@pinuke commented on GitHub (Nov 6, 2022): @KaKi87 That just makes it so much worse.

GiteaMirror commented

@pinuke commented on GitHub (Nov 6, 2022):

Just so it's clear, these comments get sent out to subscribers through their emails. This means that this kind of behavior goes against the Github Acceptable Use Policy.

These kind of comments are also considerably off-topic which is also against multiple policies in the Acceptable Use Policies and GIthub Terms of Service. To find out what's on topic for GH Issues please see https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues

@pinuke commented on GitHub (Nov 6, 2022): **Just so it's clear, these comments get sent out to subscribers through their emails.** This means that this kind of behavior goes against the [Github Acceptable Use Policy](https://docs.github.com/en/site-policy/acceptable-use-policies/github-disrupting-the-experience-of-other-users#:~:text=Engaging%20with%20platform%20features%20in%20a%20way%20that%20causes%20excessive%20notifications%20for%20other%20users). These kind of comments are also considerably off-topic which is also against multiple policies in the Acceptable Use Policies and GIthub Terms of Service. To find out what's on topic for GH Issues please see https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues

GiteaMirror commented

@oktasense commented on GitHub (Jan 13, 2024):

As of Jan 13 2024, you can add inline comments in commits:

@oktasense commented on GitHub (Jan 13, 2024): As of Jan 13 2024, you can add inline comments in commits: ![gitea-inline-comment-commits](https://github.com/go-gitea/gitea/assets/35385706/17fe79d5-9a8f-4b91-a4d0-e46282090dac)

GiteaMirror commented

@KaKi87 commented on GitHub (Jan 13, 2024):

In which version ?

@KaKi87 commented on GitHub (Jan 13, 2024): In which version ?

GiteaMirror commented

@delvh commented on GitHub (Jan 13, 2024):

Erm… What?
I think you have slightly misunderstood what is meant by that, @oktasense.
It is meant as

not what you have posted.

And that is not yet supported.

@delvh commented on GitHub (Jan 13, 2024): Erm… What? I think you have slightly misunderstood what is meant by that, @oktasense. It is meant as ![image](https://github.com/go-gitea/gitea/assets/51889757/a0684d60-f4d5-4fa2-b0b2-6fa06b8c24a7) not what you have posted. And that is not yet supported.

GiteaMirror commented

@egelhaus commented on GitHub (Oct 13, 2024):

Is there any current Update to this Feature or?

@egelhaus commented on GitHub (Oct 13, 2024): Is there any current Update to this Feature or?

GiteaMirror commented

@algora-pbc[bot] commented on GitHub (Oct 14, 2024):

💎 $300 bounty • Gitea

Steps to solve:

Start working: Comment /attempt #4898 with your implementation plan
Submit work: Create a pull request including /claim #4898 in the PR body to claim the bounty
Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

❗ Important guidelines:

To claim a bounty, you need to provide a short demo video of your changes in your pull request
If anything is unclear, ask for clarification before starting as this will help avoid potential rework
Low quality AI PRs will not receive review and will be closed
Do not ask to be assigned unless you've contributed before

Thank you for contributing to go-gitea/gitea!

Attempt	Started (UTC)	Solution	Actions
🟢 @ktamas77	Oct 05, 2025, 07:16:13 PM	#35589	Reward
🟢 @coder1125	Aug 08, 2025, 04:41:00 PM	#35240	Reward
🟢 @RedCocoon	Oct 17, 2024, 08:49:13 AM	#32384	Reward
🟢 @jayantpranjal0	Oct 31, 2025, 01:53:42 AM	WIP

@algora-pbc[bot] commented on GitHub (Oct 14, 2024): ## 💎 $300 bounty [• Gitea](https://algora.io/go-gitea) ### Steps to solve: 1. **Start working**: Comment `/attempt #4898` with your implementation plan 2. **Submit work**: Create a pull request including `/claim #4898` in the PR body to claim the bounty 3. **Receive payment**: 100% of the bounty is received 2-5 days post-reward. [Make sure you are eligible for payouts](https://algora.io/docs/payments#supported-countries-regions) ### ❗ Important guidelines: - To claim a bounty, you need to **provide a short demo video** of your changes in your pull request - If anything is unclear, **ask for clarification** before starting as this will help avoid potential rework - Low quality AI PRs will not receive review and will be closed - Do not ask to be assigned unless you've contributed before Thank you for contributing to go-gitea/gitea! | Attempt | Started (UTC) | Solution | Actions | | --- | --- | --- | --- | | 🟢 @ktamas77 | Oct 05, 2025, 07:16:13 PM | #35589 | [Reward](https://algora.io/claims/Gu4EAanAdAauwuq5) | | 🟢 @coder1125 | Aug 08, 2025, 04:41:00 PM | #35240 | [Reward](https://algora.io/claims/2WeTFLGUgCmDifME) | | 🟢 @RedCocoon | Oct 17, 2024, 08:49:13 AM | #32384 | [Reward](https://algora.io/claims/cm2w035gc0006l103yr3eoat8) | | 🟢 @jayantpranjal0 | Oct 31, 2025, 01:53:42 AM | WIP | |

GiteaMirror commented

@RedCocoon commented on GitHub (Oct 17, 2024):

Personally really interested in this gitea thing so imma give it a shot
/attempt #4898

@RedCocoon commented on GitHub (Oct 17, 2024): Personally really interested in this gitea thing so imma give it a shot /attempt #4898

GiteaMirror commented

@RedCocoon commented on GitHub (Oct 21, 2024):

I think I have come up with a solution, though not a good solution by any stretch of imagination.

First, the problem: Currently, conversations in Gitea are too closely tied to Issues to be reusable nicely anywhere else. Gitea's Pull Request itself from what I can see also janks it way by using Issues and that itself also causes a lot of troubles.

My proposed solution would be to refactor conversations so that they are standalone and can be reusable elsewhere. For my PR, I would only extract out conversations from Issues. I would however, not fix the jank introduced by Gitea's Pull Request conversation.

Please let me know if this is a good idea, or propose some other solutions. IMO my proposed solution is the best way moving forward. I've spent 4 days thinking and this is the best I could come up with. I really don't wanna do my proposed solution since it is a lot of work so if there is a better idea please suggest it!

I will now respond to every questions here first.

So If we can comment on any commit. We should consider some implementation things below:
1. Where should the comments stored, currently all comments stored with an issue(pr)

2. We have to notify all related users(who?) via UI/mail and etc.

A new Conversation table, that is context-agnostic, such that everything that needs a conversation can just reuse it. (will add backwards compatibility for issues/pr.)
Similar to Github's implementation, we will only notify all participants that have not opted out (a.k.a. everyone that commented). Different from IssuePR, there is no "First Poster" for a Conversation. Additionally, maybe the owner of the Repo and people watching the Repo? Feel free to discuss more regarding this.

I'd recommend a structure like this - There would be two different kinds of comment on commits: One on the upstream code and one on the PR.
* Both the comment on commit can be linked to the repo (the repo ID as the primary key). That way, Even when the PR gets merged, the comment still stays. We could use a composite key of the commit hash and the repo ID as the primary key.

A. Currently the comment are still there when a PR is merged, as PR is just using issues, so no problems there

I suspect we should leverage git notes or git notes-like behaviour for this. I suspect that putting this in to the database is only going to cause trouble. I wonder if the comments on PRs should do the same.

A. If my proposal is approved, someone else can take on the task of separating PRs from Issues and that is what I believe should be done eventually too.

We also need refactor notification system to notify via ui/mail/webhook and etc.

A. Yes. It will be a very massive pain.

@RedCocoon commented on GitHub (Oct 21, 2024): I think I have come up with a solution, though not a good solution by any stretch of imagination. First, the problem: Currently, conversations in Gitea are too closely tied to Issues to be reusable nicely anywhere else. Gitea's Pull Request itself from what I can see also janks it way by using Issues and that itself also causes a lot of troubles. My proposed solution would be to refactor conversations so that they are standalone and can be reusable elsewhere. For my PR, I would only extract out conversations from Issues. I would however, not fix the jank introduced by Gitea's Pull Request conversation. Please let me know if this is a good idea, or propose some other solutions. IMO my proposed solution is the best way moving forward. I've spent 4 days thinking and this is the best I could come up with. _I really don't wanna do my proposed solution since it is a lot of work so if there is a better idea please suggest it!_ I will now respond to every questions here first. > So If we can comment on any commit. We should consider some implementation things below: > > 1. Where should the comments stored, currently all comments stored with an issue(pr) > > 2. We have to notify all related users(who?) via UI/mail and etc. 1. A new Conversation table, that is context-agnostic, such that everything that needs a conversation can just reuse it. (will add backwards compatibility for issues/pr.) 2. Similar to Github's implementation, we will only notify all participants that have not opted out (a.k.a. everyone that commented). Different from IssuePR, there is no "First Poster" for a Conversation. Additionally, maybe the owner of the Repo and people watching the Repo? Feel free to discuss more regarding this. > I'd recommend a structure like this - There would be two different kinds of comment on commits: One on the upstream code and one on the PR. > > * Both the comment on commit can be linked to the repo (the repo ID as the primary key). That way, Even when the PR gets merged, the comment still stays. We could use a composite key of the commit hash and the repo ID as the primary key. A. Currently the comment are still there when a PR is merged, as PR is just using issues, so no problems there > I suspect we should leverage git notes or git notes-like behaviour for this. I suspect that putting this in to the database is only going to cause trouble. I wonder if the comments on PRs should do the same. A. If my proposal is approved, someone else can take on the task of separating PRs from Issues and that is what I believe should be done eventually too. > We also need refactor notification system to notify via ui/mail/webhook and etc. A. Yes. It will be a very massive pain.

GiteaMirror commented

@lunny commented on GitHub (Oct 21, 2024):

Thinking the issue again, maybe a new table but not comment is better? Commit commments could be a standalone thing which will not mix with issues comment and pull request comments.

@lunny commented on GitHub (Oct 21, 2024): Thinking the issue again, maybe a new table but not comment is better? Commit commments could be a standalone thing which will not mix with issues comment and pull request comments.

GiteaMirror commented

@RedCocoon commented on GitHub (Oct 21, 2024):

The problem with that is we potentially need to re-implement quite a lot and maintain both Commit Comments and IssuePR Comments (which are more like ConversationEvent rather than Comments tbh).

I suppose I can make them separate for now, since I already decoupled everything related to comments from the front-end. Let me try to keep it separate for now.

For the future though someone should definitely unify them.

@RedCocoon commented on GitHub (Oct 21, 2024): The problem with that is we potentially need to re-implement quite a lot and maintain both Commit Comments and IssuePR Comments (which are more like ConversationEvent rather than Comments tbh). I suppose I can make them separate for now, since I already decoupled everything related to comments from the front-end. Let me try to keep it separate for now. For the future though someone should definitely unify them.

GiteaMirror commented

@algora-pbc[bot] commented on GitHub (Oct 30, 2024):

💡 @RedCocoon submitted a pull request that claims the bounty. You can visit your bounty board to reward.

@algora-pbc[bot] commented on GitHub (Oct 30, 2024): 💡 @RedCocoon submitted a [pull request](https://github.com/go-gitea/gitea/pull/32384) that claims the bounty. You can [visit your bounty board](https://console.algora.io/org/go-gitea/bounties) to reward.

GiteaMirror commented

@anonhostpi commented on GitHub (Oct 30, 2024):

One concern I have is that I think inline conversations should be linked to git blames. This way relevant conversations follow the correct positioning between commits and are automatically "hidden" when a line is overwritten.

I suggest that comments be linked with an web element system instead of being hard-tied to standard repository elements for flexibility. This would require a robust web element tracking system similar to SalesForce, but would allow you to attach conversations to anything.

@anonhostpi commented on GitHub (Oct 30, 2024): One concern I have is that I think inline conversations should be linked to git blames. This way relevant conversations follow the correct positioning between commits and are automatically "hidden" when a line is overwritten. I suggest that comments be linked with an web element system instead of being hard-tied to standard repository elements for flexibility. This would require a robust web element tracking system similar to SalesForce, but would allow you to attach conversations to anything.

GiteaMirror commented

@RedCocoon commented on GitHub (Oct 30, 2024):

Currently my reimplementation is almost context-agnostic, kinda.
The conversation model doesn't really care what it is attached to, it is
standalone.
Some codes are assuming it being attached to a commit, but it is coded in
such a way that you just need a switch case in those places to return the
right values (primarily used for returning URLs)

@RedCocoon commented on GitHub (Oct 30, 2024): Currently my reimplementation is almost context-agnostic, kinda. The conversation model doesn't really care what it is attached to, it is standalone. Some codes are assuming it being attached to a commit, but it is coded in such a way that you just need a switch case in those places to return the right values (primarily used for returning URLs)

GiteaMirror commented

@anonhostpi commented on GitHub (Oct 30, 2024):

Another thought I just had is that attaching inline comments to blames would also allow conversations to be propagated between views (forks, code in issues, code in PRs, commits, older commits) and allow them to be seen in/added to other views like branch/head comparisons.

@anonhostpi commented on GitHub (Oct 30, 2024): Another thought I just had is that attaching inline comments to blames would also allow conversations to be _propagated_ between views (forks, code in issues, code in PRs, commits, older commits) and allow them to be seen in/added to other views like branch/head comparisons.

GiteaMirror commented

@RedCocoon commented on GitHub (Oct 30, 2024):

That could be possible in the future, yes. But for now I'm just focusing on
feature parity with Github

@RedCocoon commented on GitHub (Oct 30, 2024): That could be possible in the future, yes. But for now I'm just focusing on feature parity with Github

GiteaMirror commented

@olexij-christian commented on GitHub (May 28, 2025):

@lunny I can do this, right?
Is it still relevant?

@olexij-christian commented on GitHub (May 28, 2025): @lunny I can do this, right? Is it still relevant?

GiteaMirror commented

@lunny commented on GitHub (May 31, 2025):

Yes. You can try. It's better to have a proposal about your design to reduce review feedback.

@lunny commented on GitHub (May 31, 2025): Yes. You can try. It's better to have a proposal about your design to reduce review feedback.

GiteaMirror commented

@naaa760 commented on GitHub (Jul 9, 2025):

can I still work on this issue??

@naaa760 commented on GitHub (Jul 9, 2025): can I still work on this issue??

GiteaMirror commented

@wxiaoguang commented on GitHub (Jul 9, 2025):

Thank you very much!

This feature is not an easy task. Copying-pasting or AI-coding won't work. If a PR contains too many problems, it would be very difficult to review and unlikely to be merged.

For new contributors, if you'd like to try, I would suggest to start from some "good first issues", you can try to do something in the modules that are related to this feature, and get familiar to the code base, then start the challenging work.

#35015

@wxiaoguang commented on GitHub (Jul 9, 2025): Thank you very much! This feature is not an easy task. Copying-pasting or AI-coding won't work. If a PR contains too many problems, it would be very difficult to review and unlikely to be merged. For new contributors, if you'd like to try, I would suggest to start from some "good first issues", you can try to do something in the modules that are related to this feature, and get familiar to the code base, then start the challenging work. * #35015

GiteaMirror commented

@wxiaoguang commented on GitHub (Jul 9, 2025):

And for @RedCocoon's solution and PR:

Overall I think the solution is right: we can/should introduce a unified conversation system. Then issues, PRs and commit comments (even GitHub-like "discussions") can reuse it.

The problem is that the "roadmap": how to achieve this goal. Copying existing code into a new system just causes maintainability problems. And I do not think we should depend on the assumption that "someone else can take on the task of ..." or "for the future though someone should definitely unify them". Who will be "the one" then? If no one, how to maintain the code ..... To be frank, if someone has been maintaining Gitea for long time, then I can trust them and merge their temporary PRs if they say "I promise that I will fix it eventually". But for many individual feature PRs, I have to help to maintain their code because I can't assume that every contributor has time after their PR gets merged.

The feasible plan in my mind is to implement the solution step by step with a complete design, for example: split common code, introduce a general purpose "conversation system", refactor and migrate issues and PRs to use the new system, then the last step, implement the "commit inline comments". OR never migrate the issues/PRs, only use the new conversation system for the commit comments, then don't touch the old code.

Disclaimer: I am not native English speaker, so some of the expressions might not be accurate, and that's just my personal opinion.

@wxiaoguang commented on GitHub (Jul 9, 2025): And for @RedCocoon's solution and PR: Overall I think the solution is right: we can/should introduce a unified conversation system. Then issues, PRs and commit comments (even GitHub-like "discussions") can reuse it. The problem is that the "roadmap": how to achieve this goal. Copying existing code into a new system just causes maintainability problems. And I do not think we should depend on the assumption that "someone else can take on the task of ..." or "for the future though someone should definitely unify them". Who will be "the one" then? If no one, how to maintain the code ..... To be frank, if someone has been maintaining Gitea for long time, then I can trust them and merge their temporary PRs if they say "I promise that I will fix it eventually". But for many individual feature PRs, I have to help to maintain their code because I can't assume that every contributor has time after their PR gets merged. The feasible plan in my mind is to implement the solution step by step with a complete design, for example: split common code, introduce a general purpose "conversation system", refactor and migrate issues and PRs to use the new system, then the last step, implement the "commit inline comments". **OR** never migrate the issues/PRs, only use the new conversation system for the commit comments, then don't touch the old code. Disclaimer: I am not native English speaker, so some of the expressions might not be accurate, and that's just my personal opinion.

GiteaMirror commented

@mohamed1408 commented on GitHub (Jul 26, 2025):

Hi @lunny I like to work on this. Following is my proposal

We don't have to have separate table for inline comments on commits outside PR. If the comment doesn't have PRId mapped to it and only has CommitId, LineId and RepoId it is inline comment exclusively for commit.

If a commit has inline comment outside PR and this commit belongs to a PR we don't show that inline comment inside the PR

Now for notifying We have to notify

author of the commit
Owner of the repo
Participants
Collaborators
mentions inthe comment

If this is OK I can start the work, any corrections, modifications please specify.

@mohamed1408 commented on GitHub (Jul 26, 2025): Hi @lunny I like to work on this. Following is my proposal We don't have to have separate table for inline comments on commits outside PR. If the comment doesn't have PRId mapped to it and only has CommitId, LineId and RepoId it is inline comment exclusively for commit. If a commit has inline comment outside PR and this commit belongs to a PR we don't show that inline comment inside the PR Now for notifying We have to notify 1. author of the commit 2. Owner of the repo 3. Participants 4. Collaborators 5. mentions inthe comment If this is OK I can start the work, any corrections, modifications please specify.

GiteaMirror commented

@mohamed1408 commented on GitHub (Jul 27, 2025):

Am I good to go @lunny @wxiaoguang

@mohamed1408 commented on GitHub (Jul 27, 2025): Am I good to go @lunny @wxiaoguang

GiteaMirror commented

@lunny commented on GitHub (Jul 27, 2025):

If we want to store the comment in the original comment table, we’ll need to introduce at least a new comment type. Since there’s no issue_id, we can use ref_repo_id as the repository identifier and add a new index on commit_sha for lookup.

One question to consider: Should the comment only be displayed on the single commit view, or should it also appear on compare pages that include this commit?

@lunny commented on GitHub (Jul 27, 2025): If we want to store the comment in the original comment table, we’ll need to introduce at least a new comment type. Since there’s no issue_id, we can use ref_repo_id as the repository identifier and add a new index on commit_sha for lookup. One question to consider: Should the comment only be displayed on the single commit view, or should it also appear on compare pages that include this commit?

GiteaMirror commented

@mohamed1408 commented on GitHub (Jul 27, 2025):

@lunny According to me the comment should be visible in single commit page if it the comment was made out of PR directly to comment not on compare pages - PR pages and this how GitHub has implemented.

My view is

If we make an inline comment for a commit it is made by keeping in mind the effects the commit has on the branch the commit is pushed to.
If the comment is made inside a PR it is made by keeping in mind the effect the commit will have on the branch the commit is going to be merged to.

So for the above sake it is better to show them spearately and I think the GitHub has made is so too

@mohamed1408 commented on GitHub (Jul 27, 2025): @lunny According to me the comment should be visible in single commit page if it the comment was made out of PR directly to comment not on compare pages - PR pages and this how GitHub has implemented. My view is If we make an inline comment for a commit it is made by keeping in mind the effects the commit has on the branch the commit is pushed to. If the comment is made inside a PR it is made by keeping in mind the effect the commit will have on the branch the commit is going to be merged to. So for the above sake it is better to show them spearately and I think the GitHub has made is so too

GiteaMirror commented

@mohamed1408 commented on GitHub (Jul 31, 2025):

@lunny is this flow ok?

@mohamed1408 commented on GitHub (Jul 31, 2025): @lunny is this flow ok?

GiteaMirror commented