Add inline comments on commits

[tonivj5]

Add comments on commits (not only in PR), I would love to have this feature 😃

Reference: #124, #124 (comment)

Thanks to gitea's team and contributors ❤️

[LukeOwlclaw]

Sorry, I don't want to be rude nor a smartass, I just want to understand. Is this issue about

Pull/Merge request inline comments

which is supposed to be already supported according to https://docs.gitea.io/en-us/comparison/ ?

[techknowlogick]

@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).

[rakshith-ravi]

@xxxTonixxx is there a PR that currently addresses this?

[tonivj5]

I think no 😢

[rakshith-ravi]

@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 😅

[techknowlogick]

@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 :)

[stale]

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.

[tonivj5]

Not yet, please 😢

[ghost]

Yeah this would be fantastic!

[6543]

Vote

[lunny]

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.

[rakshith-ravi]

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

[zeripath]

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]

@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.

[lunny]

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

[BaxAndrei]

Yes, like on github

[0x416c69]

Vote.

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

[guillep2k]

@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....

[BaxAndrei]

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.

[lunny]

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

[0x416c69]

@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.

[jcfigueiredo]

@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ȼ

[techknowlogick]

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

[Albirew]

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 b822518 may make this issue reappear", "the changes on modules/setting/queue.go lines 58-59 of commit c779ac1 breaks this PR", etc.)

[pinuke]

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]

@KaKi87 That just makes it so much worse.

[pinuke]

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

[KaKi87]

In which version ?

[delvh]

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.

[egelhaus]

Is there any current Update to this Feature or?

[algora-pbc]

💎 $300 bounty • 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

Thank you for contributing to go-gitea/gitea!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @RedCocoon	Oct 17, 2024, 8:49:13 AM	#32384

[RedCocoon]

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

[RedCocoon]

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.

[lunny]

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.

[RedCocoon]

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.

[algora-pbc]

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

[anonhostpi]

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.

[RedCocoon]

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)

[anonhostpi]

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.

[RedCocoon]

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