Code Review from the Command Line | Hacker News Reader

Code Review from the Command Line

blog.jez.io

169 pointswinkywooster24 comments

`git depgraph` is really interesting, but it's based on Madge[1], which looks JS-specific. Does anyone know of something like Madge which is cross-language, that is, resolves references between files in Nix, Python, Java, JS, Ruby, Rust, Bash, etc?

`git heatmap`[2] is also cool. It should be easy to implement as an alias; this is 80% of the way there:

  git log --name-status --pretty=format: | sed '/^$/d' | cut --fields=2- | sort | uniq --count | sort --numeric-sort --reverse | head

[1] https://github.com/jez/git-madge

[2] https://github.com/jez/git-heatmap

There is an interesting take on command-line code review from Jane Street here https://blog.janestreet.com/putting-the-i-back-in-ide-toward...

Adding cr comments as actual comments in code is a really interesting take on code review. Never seen that before.

Me neither! I at first thought "hey, that's cool", but then I realized that the replies would also have to be in the code, and then it's no longer as appealing to me. And what do you do if you want to have a back and forth discussion? Take it "offline"?

You can get pretty far with git builtins.

When you're looking to review what happened on $review_branch, you really only need to lookup where their branch begins, and then take look at the diffs.

Where the branch "begins" is the merge-base of your current commit (assuming you're up to date) and the review branch tip.

    review_branch=origin/branch-name
    branch_point=$(git merge-base $review_branch HEAD)

    git difftool $branch_point $review_branch

One advantage is that "git difftool" has support for vimdiff and a whole bunch of other diff tools. The upside of leveraging difftool is that you can use all of the bulitin git diff stuff, eg. using `-- <path>` at the end of the command to limit the diff to just the specified paths.

If you want to diff everything in one shot, "git difftool -d/--dir-diff" will do that too.

You can also use "git difftool <commit>...<commit>" (with 3 dots).

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...

I just recently learned that there’s a --gui option for git difftool, which is nice because I use Kaleidoscope for heavy diffs (and merges too with git mergetool) but recently picked up delta [0] for quicker diffing in the terminal. Now I can have both easily.

[0]: https://github.com/dandavison/delta

There’s one thing about what’s presented here that I strongly oppose: it’s based on a single diff of all of the commits combined, rather than on reviewing individual commits. I want to see a sequence of deliberately-designed commits with good messages. If you do this, then occasionally you’ll want to view the total diff, but much more commonly it’ll be easier for all parties concerned if you look at the commits.

Putting this into practice requires very little alteration in the commands to run: `git diff --stat` becomes `git log --stat`, and `git diff` becomes `git log --patch`.

This is cool and interesting, but for me it's in the same category as photography eccentrics who can develop amazing photos with a darkroom in 2021.

I'll stick with my web interface. When that doesn't suffice, I'll check out the remote branch locally and navigate around with the full power of my IDE.

I feel like GUI vs. IDE misses a major part of the workflow. There's a lot to this workflow that isn't replicable on Github currently (dependency graph, frequently edited files, etc.). Navigating locally in your IDE is also part of this workflow, and yet is only one small part of what's being presented here.

I'd say it's closer to auto vs choosing ISO/shutter speed/f-stop.

Web tooling for git is very shallow; I wouldn't want to be without `git add/commit -p` for example.

Same here.

I was there, when cool GUIs were only available in very expensive computers, and I could buy a car or give a house entry payment with similar price points for graphical workstations.

I really don't get the point why people keep doing the extra mile to work just like we were forced to during the early days of computing.

They already use terminal tools to do their dev so this is about keeping within that environment to avoid unnecessary tools or context switching. It’s always good to avoid this even if you primarily use GUI tools e.g. using plugins so you don’t need to leave VSCode for instance.

As if Alt+Tab costs that much.

VSCode by definition of being Electron based has the whole power of HTML 5 and CSS at plugins disposition.

Those terminal emulations are running on top of WebGL and canvas, while emulating a 1980's VT100 terminal.

My usage of Git is a mix and I have learned/developed this habit with experience over the years.

Push, merge, pull, status, etc - those quick things from command line - preferably from the IDE terminal or sometimes standalone terminal (with quick CMD+TAB switch). Seeing quick diff before staging or committing from a pure feature rich (while not becoming overwhelming) GUI app like Sourcetree (again with window switch).

What I do not like is to do everything code and Git from command line alone. Nope, it's simply not worth it. It's like saying I want to talk using a string telephone and not a mobile or not even just speak out aloud because I need that retro feeling and that's perfectly fine if someone wants that (or if someone doesn't have an option, or it's a specific need).

I don't even want to begin to try CLI for code review. As of now the best I can get are web interfaces (and I hope it gets better - a bigger screen definitely helps), if I need to get more involved I try locally inside my IDE.

I do get that though. I really do. But I don't want to even try. Just like some of my friends get me reading paper books (only) and doing analog photography but they don't even want to try.

This is a really cool and thorough approach. I've always thought that it's strange how programmers are extremely picky when it comes to tools for wiring code but they seem to accept whatever they're given for reviewing code.

Shameless plug: that's why I made CodeApprove (https://CodeApprove.com). I think we can do a lot better than what GitHub offers by default.

Nice trick with including all the changed files into the review alias. One thing that always bugged me about git difftool is it runs your configured diff.tool on each changed file one-by-one. When reviewing code you quite frequently have to toggle back and forth between files, which then becomes very tedious.

> One thing that always bugged me about git difftool is it runs your configured diff.tool on each changed file one-by-one. When reviewing code you quite frequently have to toggle back and forth between files, which then becomes very tedious.

You can specify which files with git difftool by adding `-- <paths>`.

That still prompts for every file in that list. Which can be skipped with the -y flag, but that's not enough either.

What i want is one tab per changed file in my difftool of choice so i can toggle between them with just one click, not having to open-close-open-close all the time.

I wrote https://github.com/junkblocker/patchreview-vim for exactly that workflow.

Maybe for an initial look through but most of my code reviews involve a conversation with everyone involved. It would be difficult to keep track of the that locally IMO. (Small exception: IDEs like IntelliJ let you sync comments so you can have the whole thread within your IDE)

For GitHub/vscode combination, there's a plugin that let's me see/add/edit comments locally for a pull request. No idea what is available in vim or emacs.

https://github.com/pwntester/octo.nvim

For Emacs, there's an extension to Magit called "forge":

https://github.com/magit/forge https://magit.vc/manual/forge.html

It allows working with issues and PR/MR from within Emacs.

Reply on news.ycombinator.com