You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add the ability to delete the "last" comment, similar to --edit-last #10366
Describe the feature or problem you’d like to solve
I'd love to see a way to delete PR and issue comments with the CLI.
This previous issue highlighted some questions/friction around a potential delete --id 1234 type command, which I think are valid concerns.
I'd like to propose an ability to delete comments by building off of the existing behavior of --edit-last
Proposed solution
gh [issue|pr] comment --edit-last --delete or gh [issue|pr] comment --delete-last
This command would remove the last comment made by the CLI user, similar to how --edit-last works.
This would benefit users by offering some type of comment delete functionality in the CLI, while avoiding the complexity/uncertainty of having to discover a comment ID to supply to the delete command.
This would align with existing behavior (--edit-last flag)
Additional context
I don't think this would totally solve all the requests for a "delete comment" type command. It may solve a portion of them (e.g. use cases that leverage CI bots to leave comments) - maybe that is an acceptable compromise.
Hey @erawhctim, this is an interesting idea... I am slightly concerned around unintentional deletion, such as if the latest comment isn't what you thought it was. I think we can probably mitigate this with a confirmation flag like we do in a lot of delete commands, though its a bit awkward given its a flag and another flag. Not unprecedented, though, like with the --accept-visibility-change-consequences flag in the gh repo edit --visibility command.
As such, I think my design would be as such:
Acceptance Criteria
Given I have commented on an open PR when I invoke gh pr comment [<number> | <url> | <branch>] --delete-last interactively then I am shown the comment I will be deleting and prompted to confirm deletion. If deletion is confirmed, the comment is deleted.
Given I have not commented on an open PR when I invoke gh pr comment [<number> | <url> | <branch>] --delete-last then the command fails and I'm shown a message stating I haven't commented on the PR yet
Given I have commented on an open PR when I invoke gh pr comment [<number> | <url> | <branch>] --delete-last --yes interactively then the last pr comment I made is deleted and I am shown a deletion success message
Given I have commented on an open PR when I invoke gh pr comment [<number> | <url> | <branch>] --delete-last non-interactively then the command fails and I'm shown a message stating that I must use the --yes flag with the --delete-last flag when using the flag non-interactively
Given I have commented on an open PR when I invoke gh pr comment [<number> | <url> | <branch>] --delete-last --yes non-interactively then the last pr comment I made is deleted
Given all of the above scenarios for an issue when I invoke the corresponding gh issue comment command then I experience the same behavior as the corresponding gh pr comment scenarios above
(i.e. gh issue comment --delete-last should behave the same as gh pr comment --delete-last as enumerated by the AC above)
@sinansonmez, you're welcome to break it up as well, though there's a lot of shared code between issues/prs that might make it easier to do all at once. Either way, feel free to work however you'd prefer 🙂
@jtmcg yes you were right, it was much easier than I though to implement all at once thanks to the shared code. Please take a look at the PR when you have time 😄
Activity
erawhctim commentedon Feb 3, 2025
Would be happy to try and submit a PR for this, similar to #6384
jtmcg commentedon Feb 4, 2025
Hey @erawhctim, this is an interesting idea... I am slightly concerned around unintentional deletion, such as if the latest comment isn't what you thought it was. I think we can probably mitigate this with a confirmation flag like we do in a lot of
deletecommands, though its a bit awkward given its a flag and another flag. Not unprecedented, though, like with the--accept-visibility-change-consequencesflag in thegh repo edit --visibilitycommand.As such, I think my design would be as such:
Acceptance Criteria
Given I have commented on an open PR
when I invoke
gh pr comment [<number> | <url> | <branch>] --delete-lastinteractivelythen I am shown the comment I will be deleting and prompted to confirm deletion. If deletion is confirmed, the comment is deleted.
Given I have not commented on an open PR
when I invoke
gh pr comment [<number> | <url> | <branch>] --delete-lastthen the command fails and I'm shown a message stating I haven't commented on the PR yet
Given I have commented on an open PR
when I invoke
gh pr comment [<number> | <url> | <branch>] --delete-last --yesinteractivelythen the last pr comment I made is deleted and I am shown a deletion success message
Given I have commented on an open PR
when I invoke
gh pr comment [<number> | <url> | <branch>] --delete-lastnon-interactivelythen the command fails and I'm shown a message stating that I must use the
--yesflag with the--delete-lastflag when using the flag non-interactivelyGiven I have commented on an open PR
when I invoke
gh pr comment [<number> | <url> | <branch>] --delete-last --yesnon-interactivelythen the last pr comment I made is deleted
Given all of the above scenarios for an issue
when I invoke the corresponding
gh issue comment commandthen I experience the same behavior as the corresponding
gh pr commentscenarios above(i.e.
gh issue comment --delete-lastshould behave the same asgh pr comment --delete-lastas enumerated by the AC above)Did I miss anything?
erawhctim commentedon Feb 4, 2025
I think you nailed it.
jtmcg commentedon Feb 4, 2025
Awesome! Feel free to take a stab at it, @erawhctim, if you're still interested
sinansonmez commentedon Mar 13, 2025
@jtmcg I am interested to take stab at it. Is it OK to split the PR into 2 parts (i.e. 1 for issue and 1 for PR)?
erawhctim commentedon Mar 14, 2025
@sinansonmez feel free to tackle all of it at once if you'd prefer
jtmcg commentedon Mar 14, 2025
@sinansonmez, you're welcome to break it up as well, though there's a lot of shared code between issues/prs that might make it easier to do all at once. Either way, feel free to work however you'd prefer 🙂
sinansonmez commentedon Mar 14, 2025
@jtmcg yes you were right, it was much easier than I though to implement all at once thanks to the shared code. Please take a look at the PR when you have time 😄