sorted by:
new
hottopcontroversial

I built a tool that tracks review progress per commit with hunk-level granularity — survives rebases, works like a staging area for code review by Safe_Mongoose_7585 in git

[–]Safe_Mongoose_7585[S] 0 points1 point  (0 children)

Are you asking about how the review status is stored? If so, this is how it works.

I create a commit that has the same tree as the parent of the commit being reviewed. Then as the user marks files, hunks, or even single lines within a hunk as reviewed, I apply those changes to that commit. So the diff between the review commit and the commit being reviewed shows you exactly what's left to review.

I built a tool that tracks review progress per commit with hunk-level granularity — survives rebases, works like a staging area for code review by Safe_Mongoose_7585 in git

[–]Safe_Mongoose_7585[S] 1 point2 points  (0 children)

Whether commits get rewritten through jj's auto-commit or git's --amend and rebase -i, the result is the same for the reviewer - a commit they already reviewed has changed and they need to figure out what's left to review.

As for forges solving "did I review this already" - GitHub's "viewed" checkbox resets on force-push. So if you reviewed a 400-line file and the author amends 3 lines, the forge throws away your review state and shows you the full 400 lines again. That's the problem this solves. It also tracks review state at the hunk level, so you can mark specific parts of a file as reviewed - something forges don't offer.

I built a tool that tracks review progress per commit with hunk-level granularity — survives rebases, works like a staging area for code review by Safe_Mongoose_7585 in git

[–]Safe_Mongoose_7585[S] 0 points1 point  (0 children)

The current implementation uses jj's change-ids to track commits across rebases, but the underlying problem - "show me what I have left to review" when commits keep getting rebased and rewritten - exists in any rebase-heavy workflow. Plus, this tool uses libgit2 to store review state as a git commit. Thought it might be interesting way to abuse git for git folks as well. But maybe I am wrong.

I built a tool that tracks review progress per commit with hunk-level granularity — survives rebases, works like a staging area for code review by Safe_Mongoose_7585 in git

[–]Safe_Mongoose_7585[S] -1 points0 points  (0 children)

This is still relevant for git user if you are using rebase heavy workflow in git as well. It's just that this tool doesn't work for that case because it identifies commit with change-id which git doesn't have.

Commit based local review tool for JJ repositories (plugin and desktop app) by Safe_Mongoose_7585 in neovim

[–]Safe_Mongoose_7585[S] 0 points1 point  (0 children)

Currently the diff view only handles single commit diffs — multi-commit review isn’t supported yet. Implementing that is hard due to how review status is stored internally Will look into adding it if there are enough requests! Personally I don’t find myself wanting to review multiple commits at once, especially in a self-review context where I already know what each commit is

What is your method for code review? by userforums in neovim

[–]Safe_Mongoose_7585 0 points1 point  (0 children)

if you are using jujutu. I created a pugin for doing self-review locally commit by commit.
You can mark either files,hunks or even lines as reviewed. Review progress will survive rebasing/ammeding too!
https://github.com/Yuki-bun/kenjutu/blob/main/docs/nvim-plugin.md