Allow viewing the edit history of comments

[aensley]

Related to #128. Often, comments need to be edited, and that's a great feature. However, sometimes, comments are edited for not-so-good reasons, and there's no way to see the original, when it was edited, or by whom.

Edit
Adding content here in an edit to see if/when the history shows up.

[vadmeste]

👍

[neoncitylights]

+1

[koenpunt]

👍 Would really like history on comments and issues.

Had a guy promoting his repo by e-mail, saying he figured I would be interested in some random project.
I opened an issue on this repo to make my annoyance clear, and after a short conversation, he removed by comments, updated my original issue body, and updated the title to [Invalid ticket]

[joshmanders]

@koenpunt Yup, been noticing same issues with other malicious users. Deleting issue comments and retitling to Undefined or something.

[hagronnestad]

👍

[woogenius]

👍

[delvatt]

+1

[vinicius0026]

+1
By the way, is it possible to access this information via API? I was not able to do so... Any help is appreciated.

[aensley]

You can see when the issue was created and updated, but it still only gives you the last version of the body:

https://api.github.com/repos/dear-github/dear-github/issues/129

{
  "url": "https://api.github.com/repos/dear-github/dear-github/issues/129",
  "repository_url": "https://api.github.com/repos/dear-github/dear-github",
  "labels_url": "https://api.github.com/repos/dear-github/dear-github/issues/129/labels{/name}",
  "comments_url": "https://api.github.com/repos/dear-github/dear-github/issues/129/comments",
  "events_url": "https://api.github.com/repos/dear-github/dear-github/issues/129/events",
  "html_url": "https://github.com/dear-github/dear-github/issues/129",
  "id": 134635222,
  "number": 129,
  "title": "Allow viewing the edit history of comments",
  "user": {
    "login": "aensley",
    "id": 95717,
    "avatar_url": "https://avatars.githubusercontent.com/u/95717?v=3",
    "gravatar_id": "",
    "url": "https://api.github.com/users/aensley",
    "html_url": "https://github.com/aensley",
    "followers_url": "https://api.github.com/users/aensley/followers",
    "following_url": "https://api.github.com/users/aensley/following{/other_user}",
    "gists_url": "https://api.github.com/users/aensley/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/aensley/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/aensley/subscriptions",
    "organizations_url": "https://api.github.com/users/aensley/orgs",
    "repos_url": "https://api.github.com/users/aensley/repos",
    "events_url": "https://api.github.com/users/aensley/events{/privacy}",
    "received_events_url": "https://api.github.com/users/aensley/received_events",
    "type": "User",
    "site_admin": false
  },
  "labels": [

  ],
  "state": "open",
  "locked": false,
  "assignee": null,
  "milestone": null,
  "comments": 8,
  "created_at": "2016-02-18T16:54:31Z",
  "updated_at": "2016-04-11T21:36:10Z",
  "closed_at": null,
  "body": "Related to #128. Often, comments need to be edited, and that's a great feature. However, sometimes, comments are edited for not-so-good reasons, and there's no way to see the original, when it was edited, or by whom.\r\n\r\nThe GitHub API seems to offer all versions of the comments, but that information is hidden in GitHub's web interface.\r\n\r\n**Edit**\r\nAdding content here in an edit to see if/when the history shows up.",
  "closed_by": null
}

[aensley]

Same thing with comments:

https://api.github.com/repos/dear-github/dear-github/issues/comments/208573845

And now to copy in the escaped JSON content inside a JSON response so that GitHub's API/web interface can really freak out:

{
  "url": "https://api.github.com/repos/dear-github/dear-github/issues/comments/208573845",
  "html_url": "https://github.com/dear-github/dear-github/issues/129#issuecomment-208573845",
  "issue_url": "https://api.github.com/repos/dear-github/dear-github/issues/129",
  "id": 208573845,
  "user": {
    "login": "aensley",
    "id": 95717,
    "avatar_url": "https://avatars.githubusercontent.com/u/95717?v=3",
    "gravatar_id": "",
    "url": "https://api.github.com/users/aensley",
    "html_url": "https://github.com/aensley",
    "followers_url": "https://api.github.com/users/aensley/followers",
    "following_url": "https://api.github.com/users/aensley/following{/other_user}",
    "gists_url": "https://api.github.com/users/aensley/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/aensley/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/aensley/subscriptions",
    "organizations_url": "https://api.github.com/users/aensley/orgs",
    "repos_url": "https://api.github.com/users/aensley/repos",
    "events_url": "https://api.github.com/users/aensley/events{/privacy}",
    "received_events_url": "https://api.github.com/users/aensley/received_events",
    "type": "User",
    "site_admin": false
  },
  "created_at": "2016-04-11T21:38:47Z",
  "updated_at": "2016-04-11T21:39:02Z",
  "body": "You can see when the issue was created and updated, but it still only gives you the last version of the body:\r\n\r\n\r\nhttps://api.github.com/repos/dear-github/dear-github/issues/129\r\n\r\n\r\n```JSON\r\n{\r\n  \"url\": \"https://api.github.com/repos/dear-github/dear-github/issues/129\",\r\n  \"repository_url\": \"https://api.github.com/repos/dear-github/dear-github\",\r\n  \"labels_url\": \"https://api.github.com/repos/dear-github/dear-github/issues/129/labels{/name}\",\r\n  \"comments_url\": \"https://api.github.com/repos/dear-github/dear-github/issues/129/comments\",\r\n  \"events_url\": \"https://api.github.com/repos/dear-github/dear-github/issues/129/events\",\r\n  \"html_url\": \"https://github.com/dear-github/dear-github/issues/129\",\r\n  \"id\": 134635222,\r\n  \"number\": 129,\r\n  \"title\": \"Allow viewing the edit history of comments\",\r\n  \"user\": {\r\n    \"login\": \"aensley\",\r\n    \"id\": 95717,\r\n    \"avatar_url\": \"https://avatars.githubusercontent.com/u/95717?v=3\",\r\n    \"gravatar_id\": \"\",\r\n    \"url\": \"https://api.github.com/users/aensley\",\r\n    \"html_url\": \"https://github.com/aensley\",\r\n    \"followers_url\": \"https://api.github.com/users/aensley/followers\",\r\n    \"following_url\": \"https://api.github.com/users/aensley/following{/other_user}\",\r\n    \"gists_url\": \"https://api.github.com/users/aensley/gists{/gist_id}\",\r\n    \"starred_url\": \"https://api.github.com/users/aensley/starred{/owner}{/repo}\",\r\n    \"subscriptions_url\": \"https://api.github.com/users/aensley/subscriptions\",\r\n    \"organizations_url\": \"https://api.github.com/users/aensley/orgs\",\r\n    \"repos_url\": \"https://api.github.com/users/aensley/repos\",\r\n    \"events_url\": \"https://api.github.com/users/aensley/events{/privacy}\",\r\n    \"received_events_url\": \"https://api.github.com/users/aensley/received_events\",\r\n    \"type\": \"User\",\r\n    \"site_admin\": false\r\n  },\r\n  \"labels\": [\r\n\r\n  ],\r\n  \"state\": \"open\",\r\n  \"locked\": false,\r\n  \"assignee\": null,\r\n  \"milestone\": null,\r\n  \"comments\": 8,\r\n  \"created_at\": \"2016-02-18T16:54:31Z\",\r\n  \"updated_at\": \"2016-04-11T21:36:10Z\",\r\n  \"closed_at\": null,\r\n  \"body\": \"Related to #128. Often, comments need to be edited, and that's a great feature. However, sometimes, comments are edited for not-so-good reasons, and there's no way to see the original, when it was edited, or by whom.\\r\\n\\r\\nThe GitHub API seems to offer all versions of the comments, but that information is hidden in GitHub's web interface.\\r\\n\\r\\n**Edit**\\r\\nAdding content here in an edit to see if/when the history shows up.\",\r\n  \"closed_by\": null\r\n}\r\n```"
}

[vinicius0026]

Yeah, I got that... The edit history of the issue description is what I was looking for. Thanks anyway!

[aensley]

@vinicius0026 Right. And that's what this issue is asking for. :-)

[Qix-]

Github now shows when comments are edited, and who by - but not the edit history.

I'm actually in favor of this - if someone posts sensitive information in a comment and then redacts it later (or the company redacts it for them, or a bot, etc.) then it shouldn't be there to show in the history as a safety consideration.

I'd consider this closed to be fair. The only improvement they could make (and I haven't seen whether or not this is already done) is to just show by whom and when, in a list, it was edited.

[FichteFoll]

Regarding edit history, there has recently been an update blog post about integrations and commit/issue editing. Specifically, you get to see the old and the new content of edited comments (and issues) in webhooks, so technically one could develop such an integration externally. However, I have the feeling that it won't be too long until github adds this feature itself. 👍

https://github.com/blog/2156-expanded-webhook-events

[muesliq]

+1

• Nobody can
• find out
• who checked these tasks
• - and when

[jesus2099]

I think seeing our own edits is very little useful compared to seeing others’s — except your particular example. :)
The main interest of seeing edit history is by others, it allows to better understand the replies to a later edited post, for instance.

[FichteFoll]

Discourse handles editing really well. It batches edits made within 5min and has a button that displays the number of batched edits as well as a diff for each individual edit when clicked. The only "downside" is that it has a time limit on how long you can edit your posts which github currently does not. As long as OPs remain editable, I'm fine with either.

I also hope that github will wait with sending out notification emails for a few minutes because I regularly edit my posts quickly after posting them when I realize I could word them better. (Such as this one.)

[dnesting]

If GitHub implements this it is necessary for them to also have a method by which we can permanently delete information, lest PII or other sensitive data accidentally make its way into a comment. Also do not enable this feature retroactively.

[aensley]

@dnesting It may be impossible to implement retroactively anyway. I don't know if they're saving the original comments, but I doubt it.

As for sensitive information, I think the maxim "The Internet is forever" is appropriate. If somebody posts something on a public project page, they should have no expectations of being able to delete it, even if that feature is available.

[dnesting]

1. Not all comments are on publicly-visible repos
2. Just because something could have been observed doesn't mean that it is impossible for further harm to occur by continuing to make it available. People should mitigate risk as if the information were exposed to people eager to exploit it, but that doesn't mean we shouldn't have tools that let us remove the information from view, to reduce the potential for that information to be exploited by others. It's easy to change passwords and secret keys, but not so easy to reduce the harm caused by exposed health records, for instance.

[aensley]

I work in several private repos myself. I assumed you were talking about information being exposed publicly by not being able to delete it. My mistake.

[aensley]

@dnesting:

I've been thinking more about this: What if the ability to permanently delete content was limited to the comment author and repository owners only? Then make the editing occurrences (person and time only, no content) visible no matter what.

I think that would satisfy both of our concerns:

1. Knowing when/what is changed by others (including team members).
2. Still allowing the ability to permanently delete accidentally-posted sensitive information by those who should have that ability/responsibility.

[jhawlwut]

Here's a scenario regarding this topic: code reviews to meet compliance standards.

So, if you have a code review process utilizing PRs to the master branch of a private repository, it'd be great if the Org/Repo owner(s) or admin could lock down comment editing. This assumes a few things:

• If a collaborator is commenting in a private repo they are a member of that organization and or have been added as a collaborator
• If sensitive information has been posted, it's up to the owners / admins to remove the post

A big challenge right now is if an approved says a review looks good, only to edit that comment later. A workaround is labels, but verifying the original comment would be great.

Sorry for any misspellings, iPhone typed.

[aensley]

@jhawlwut That's exactly the atmosphere I'm coming from, but I know any solution/change has to work for everyone.

[cvvergara]

I ask for another scenario:
What happens when people on good faith posted a code snipet, and it happened that later he realizes that by posting the snipet he is breaking some license/agreement, and wants to delete it, including from the history?

[aensley]

@cvvergara I think that would be covered by my suggestion above: #129 (comment)

[flowmemo]

+1
BTW, is there a way to get updated time of the "0th" comment(issue's description), e.g. #129 (comment) ? The API for issue's comments is not usable.

[borekb]

By the way, GitHub support can already send you older versions of your issues and PR comments, it's just not in the UI yet.

[advanceddeveloper]

I am not a fan of this.

A user may accidentally post some sensitive or private information when reporting an issue. Making edit history permanently visible would allow anyone to access such information. The current implementation seems reasonable to me: if a user who made an edit wants to reveal that he had made a mistake, he can just put a stroke line over the previous sentence and add the correct one. But, if someone fixed a typo, I don't think it is worth storing in the history. Or if someone edited out private information.

Another idea is to allow anyone to access edit history, but also allow the author of the issue (or comment) to permanently redact some edits.

[gthackra]

you could always use a webhook to write out edits to a secondary db for storage/review etc. Webhooks are configurable to trigger on an issue comment edit and contain enough information to track issue comment edit history.

[aensley]

Replying to #129 (comment) by @advanceddeveloper:

This is a common objection that has been addressed many times in this thread. Please see:

#129 (comment)

#129 (comment)

#129 (comment)

#129 (comment)

[darkred]

Wow, GitHub has finally implemented this !!
https://twitter.com/GHchangelog/status/1000094809942507521 i.e. Tracking changes in a comment

[hoganlong]

@advanceddeveloper note, they added the ability to delete into the UI too -- seems to address your concern.

[advanceddeveloper]

@aensley

I hadn't really read all comments in this thread, I just posted my opinion, so I am not surprised that others had already said the same thing before.

@hoganlong

I'm happy to hear that.

[aensley]

As @darkred noted, this is implemented! Finally!

https://help.github.com/articles/tracking-changes-in-a-comment/

[borekb]

Well, it's been rolled back for now (confirmed by their support; they probably found some issue in it) but it will definitely come back. 🎉

[injust]

@borekb Seems like it's live.

[idgserpro]

Will comments edited before this implementation have the edit history diff or just edited comments from now on?

[borekb]

From now on (confirmed by GitHub support today).

[idgserpro]

This makes sense. Imagine having edited a comment 2 years ago that you even don't remember which one was to remove sensitive information and trying to recover which one is to fix it...

Thanks.

[GolfingSuccess]

Another thing I'd like to have as a feature is, instead of being able to "delete", being able to "hide/unhide", and, in that way, revisions of comments prior to the announcement of public comment diffs would be hidden by default.

[jbruchon]

I'd like the ability to turn this feature off.

[Wildeast]

For legal conformity reasons:

• The right to delete old version should be restrictable to the repo owner / responsible.
• Review comments can be legal documents, not to be changed by anyone, especially not the one having it written.

[Wildeast]

When is this feature available in GitHub Enterprise?

Have not seen it yet.

[dev-101]

I guess I am actually alone in this one, seeing how many of you requested this :)

I'm completely annoyed with this 'feature'. At least, GitHub should introduce 60-120 seconds grace period from initial posting to allow for minor grammar or typo fixes. It is really wasting resources to record 1 letter changes and typos imho, unless the post is edited much later or next day etc.

edit: oops typo! (unintentional, honestly)

[avbentem]

introduce 60-120 seconds grace period from initial posting

Or even much longer, unless maybe someone else meanwhile responded.

Adding a grace period would also require GitHub to postpone sending the email alerts a bit though, to ensure those reflect the most recent content. The alert I got included the first revision; no alert about the edit though.

[mesqueeb]

I want to vote +1 on 120 sec grace period + postponing the initial email of the comment until after these 120 sec.

[benbucksch]

-1 Personally, I expect a notification right away (less than 10 seconds until it's in my inbox) and consider a 2 minute email notification delay to be a bug. (I say that as someone who very often edits his comments.)

[Pacerier]

@FichteFoll re "Discourse handles editing really well".

Since it's written by SE's author who happens to be no web newb (unlike GH's founders!). Although batching updates (in the db) is stupid.

[Pacerier]

@aensley re "no expectations of being able to delete it, even if that feature is available".

Lol? That's not how the Internet works (unless the page is "high profile").

[Pacerier]

@Wildeast re "right to delete old version should be restrictable to the repo owner".

And for legal (?) conformity reasons the repo owner should not be allowed deleting of stuff he didn't write?

[Pacerier]

@dev-101 re "completely annoyed" "minor grammar or typo fixes".

You can don't edit it. and no one will be annoyed. But don't edit while wanting people to not know.

re "minor"; Typical for-you-but-not-me.