How to parse comments in a GIT commit?

Question

I am following a simplified code review process for GIT commits where developers add message in GITHUB web UI saying @review pending by @user_a, @user_b ( user_a and user_b are valid GIT users ) for direct GIT COMMITs.

Later reviewer adds another message in GITHUB web UI saying @reviewed by @reviewer_a.

Idea is to detect how many COMMITs were checked in w/o any reviews. GIT PULL requests are good place for conversations but what I am looking for is to have each COMMIT have message like @reviewed by... as it's last message.

I can list all commits added to the repository in last one week with git log --oneline --graph --after="1 week ago". But this doesn't show the comments / messages added from GITHUB web UI by requester and reviewer.

Is there a way of listing conversations in a single COMMIT / parse these conversations / messages added in GITHUB web UI?

Answer 1

Git doesn't support commit comments automatically; that's GitHub functionality, not Git functionality. You won't have much luck finding built-in git functionality to see these comments.

As far as Git is concerned, commits are immutable based on their commit messages, properties (e.g. author and timestamp), and tree. Amending commits in git would necessarily change the hash, which can interfere with anyone basing their work on the existing commit and its hash. (Git does support roughly-equivalent functionality through the git notes command, but GitHub no longer supports showing notes, and commit comments aren't a part of that.)

• If you want to match up commits on a git branch with comments made on GitHub, you'll need to use GitHub's comment API. It's impressively-documented, and should give you all the calls you need to list, add, edit, or delete comments for any given commit, or to list all the comments across your entire repo.

  I'd offer some example code, but your script is going to depend on your exact review process, balancing the number of calls you'll need (against your GitHub API rate limit) against the update rate you want.

• If this is a part of a continuously-running server or review process, you may also want to investigate the webhook-based commit comment event, which will notify your publicly-accessible endpoint when someone has made a comment. With some permanent storage and a webhook, you can easily see when commits make the jump from "submitted" to "properly reviewed".

• You can also use third-party CLI tools, like this GitHub CLI project, though I haven't used it and can vouch neither for its security nor for its utility here.

• Finally, if you do write a script of your own, remember to use the git plumbing commands, such as git rev-list instead of git log. The output of "porcelain" commands (like log and status) can change and evolve, whereas the "plumbing" commands (like cat-file and rev-list) have guaranteed predictable output perfect for long-lived scripts.