> For a large change, I don’t want to do a “diff review”, I want to do a proper code review of a codebase at a particular instant in time, paying specific attention to the recently changed areas,
obviously every team and ticket is different, but IMO unless the person doing the review is some sort of principal engineer mostly responsible for the code at large, this does not align with I would personally consider a code review. In my book a general code review is simple sanity check by a second pair of eyes, which can result in suggestions to use different API or use an API slightly differently. If commits in the PR are properly ordered/squashed it is relatively easy to review incremental changes in isolation anyway.
I guess the complaint author has is really about review types. I do not have terminology ready at hand, but there is run of the mill sanity check review and then there is deep, architectural feature premerge review. The author complains about the latter when most of the code reviews in web tools are of the former variety.
> In my book a general code review is simple sanity check by a second pair of eyes, which can result in suggestions to use different API or use an API slightly differently.
This is an impoverished view of code review. Code review is a principal mechanism for reducing individual code ownership, for propagating conventions, and for skill transfer.
A good code review starts with a good PR: one that outlines what its goals were and how it achieved them.
First item on a good review then: does the code achieve what it set out to do per the outline?
Second: does it contain tests that validate the claimed functionality?
Third: does it respect the architectural conventions of the system so far?
Fourth: is the style in line with expectations?
Fifth, and finally: do you have any suggestions as to better API usage?
A code review that is nothing more than a sanity check is useless and could have been done by CI infrastructure. Code review is a human process and should maximally take advantage of the things only humans could do. Leave the rest to machines.
An implicit question in several of the above is "will this set a good example for future contributions?"
In my book, superficial code review produces only superficial results. This is how so many bugs get shipped despite the ubiquity of code review.
Call me crazy, but I've always approached code review from the standpoint of a tester: I build and run the code, see whether it does what it's supposed to do, look for possible weak points, and try to break it.
The diffs are the beginning rather than the end. They show you where to start poking around in the code. The proof is in the pudding, though.
You might respond, "That's what testers are for, not engineers." But who can test better than someone who understands the code and knows exactly where to look and what to look for?
I know this attitude puts me in the minority. The majority of engineers seem to have an inborn horror at the prospect of, gasp, manually running code. (They're also strangely averse to using debuggers.) They'll do anything in the world and write vast infrastructure to avoid it. Automate all the things! But in my view, automation is just more possibly buggy code. Who tests the tests? Quis custodiet ipsos custodes?
I agree about what to expect from a code review - but for me, certain ways of working need to be in place for this to function properly.
A code review is the "last line of defense" (well, disregarding CI), but in the teams I've worked in, that meant that the general idea of what the PR is introducing has been discussed by multiple people at that point. (This could be either a pairing session, an in-depth explanation, or just a coffee chat, depending on the complexity) This way the PR isn't about reviewing the general strategy (splitting off a new module, introducing a huge dependency, reworking the API surface), but just about reviewing the tactics used to implement that strategy.
Without the communication beforehand, doing only sanity checks on parts of the code in isolation does run the risk of fracturing code ownership. ("What's that module doing?" "Beats me, ask bob")
That all notwithstanding, I like the author's idea of what a diff view should look like, regardless of the "mode" of reviewing.
I think you have some good truths in your post, but I also think they're rendered somewhat irrelevant by the fact that a "diff review" is, in my repeated and frequent experience, simply incomprehensible. I can't do any review with an incomprehensible mass of red and green lines interspersed with each other. It's not a useful view of the code, or at least not a useful primary view.
I push through and do it anyhow, because this is one of those "they're not paying me to have an endless party" sort of things. But I completely 100% agree with the author that it is not a very useful view.
Most of modern technology company culture has strayed too far from doing more formal processes for managing development.
By not having a basic process for defects, features, etc, every engineer has to make up and invent the process for how they will ship their feature through collaboration.
In most cases this ends up with doing little to nothing, with code review being the only form of collaboration on the topic that is in any meaningful detail. So we're left trying to stuff all possible interventions into a single moment.
> unless the person doing the review is some sort of principal engineer mostly responsible for the code at large [..] In my book a general code review is simple sanity check by a second pair of eyes
I don't necessarily disagree with you, but I don't agree either.
A typical workflow should be:
1. Engineer writes code
2. Engineer does manual and automated testing to verify things work correctly
3. Engineer commits, pushes, and creates a PR/MR
4. CI runs test suite
5. Another Engineer reviews PR/MR
6. Approval causes merge which causes deployment to staging
7. QA
8. UAT
9. Repeat steps 1-8 until everybody is happy
In this, we need to place checks on #1 and #2.
In my eyes, QA and UAT are superficial reviews/sanity checks on #2.
#3 is a check in #1. However, it relies on A) previous engineers implementing good tests and B) the current engineer doing the same. This means trusting people are doing the right things, but a Review implies you don't completely trust that.
#5 is a check on #3 and #1. They're essential. Having a full understanding of what the code looks like is more important in my mind than what was actually changed. The changes don't show how other code is interacting with those changes (which should be, but isn't always, captured by unit tests).
That's why I think the article author's preferred view is ideal. In fact, that's roughly what I work with when reviewing without realizing it (diff in GitLab/GitHub/Sublime Merge, code in JetBrains where most of the review happens).
A third (fourth?) option worth mentioning here is difftastic[0], which uses "structural" diffing (as opposed to line diffing) for more granular diff highlighting.
A fourth (fifth?) option worth mentioning is patdiff: https://opensource.janestreet.com/patdiff/ From what I remember, it sometimes (35%) made diffs easier to read, usually (60%) made no difference, and rarely (5%) made them harder to read. I used it a few years ago though, so I don't remember specifically what the problem was. The only reason I stopped using it was because I started using magit for git diffs.
This is a great approach indeed, pity it's not integrated widely enough (think it only recently got a proper structured json output other tools could use)
* A little scripting around opening the PR, which basically performs a "vimdiff <(git show baseref:file) file"-style dance on the changes(see :h diff). Using vim's tabs is great for this as they're really only views, so you can hold individual buffers open in distinct states at the same time.
* Scroll locking still works as expected in the main view, but you can avoid it in a separate tab when needed.
* [c and ]c move between hunks from the set of changes as they exist in the PR not in the working directory.
* dp and dg allow you to mark hunks as "done" by pushing/pulling the hunk in to the read-only diff buffer so that they're now hidden from the highlighted changes in the live buffer.
* Changes you make in the live buffer are available to commit directly, or push as a comment.
* All your regular editor things work as expected in the current state of the tree; go to definition, build integration, popup docs, etc.
Working like this means you're viewing changes against the PR's base, but have a clean working directory. That, to me, feels like a significant improvement over matklad's solution of having the working directory be in an unclean state to view the changes.
The environment I work in makes this behaviour super nice as changes will often be added with a --fixup commit, and then the tooling mangles them back together with a git-interpret-trailers call to attribute the fixup commit's author to the original commit at merge time. It also pulls text comments out of the PR and attaches a Reviewed-by trailer where appropriate, or the +1 equivalent to tack an Acked-by trailer on.
A somewhat minor nitpick, the word huge begins with a consonant sound, not a vowel sound. It would be correct to write "a huge issue" not "an huge issue".
I'm probably missing something here: author says that the split diff doesn't work for him, but doesn't say why.
His ideal diff is pretty much the same as a split-diff but with redundant context removed (context is only on the left, not on both left and right). What utility does he get out of removing redundant context on the RHS of the pane?
> I need to run tests, use goto definition and other editor navigation features, apply local changes to check if some things could have been written differently, look at the wider context to notice things that should have been changed, and in general notice anything that might be not quite right with the codebase, irrespective of the historical path to the current state of the code.
The editors/IDEs I've used usually only offer rudimentary support in diffs (goto defn, but only in the same file; maybe auto-completion, but usually not for newly added items; no refactoring functionality)
LHS shows current code, without any modifications. By showing full context in one view (with code browsing capabilities!) and changes in the other, the author is able to browse the code and see what changes, if any, are applied in a particular context.
In my understanding the author wants to flip the diff around: instead of looking at changes themselves, the author wants to look at code and see if there are any associated changes.
The article is light on detail, but my guess would be that author wants to look at code and browse to implementation/callsite to check if appropriate changes are there.
I'm not the author, but I can empathise with them.
The diff highlighting can be surprisingly distracting and it can definitely help readability to turn it off. I certainly do turn it off from time to time in my diff viewer so I can see the code with fresh eyes, but I don't have the option to show the unified diff in a split pane.
If you hit `.` in GitHub, you'll get dropped into a full IDE inside the browser. I've found this to be invaluable for reviews, because it lets you see the changes within the context of the entire file, rather than just seeing snippets. I'm much more likely to catch subtle design issues that way.
ok this is really cool, thanks for the tip! I've been in this IDE before but only when making edits to files directly in Github. I did not know I could shortcut to it directly from a commit diff.
By the way, this shortcut also works in Gitlab (just tried it)
I miss some of the capabilities from p4merge such as the split diff having a margin inbetween showing which parts of the file correspond to the other file, whilst also showing the impact of the diff on both sides: https://www.perforce.com/manuals/p4merge/Content/P4Merge/dif...
these features never made it into the web based diff tools that are widespread, I think the 3 way diff is a be a good way to show result of a difficult merge
Which is a travesty because a side by side diff view with an out-of-line list of PR comments could be incredibly useful if it didn't involve spinning up a whole VSCode instance in the browser. In fact it's so useful that GH used to have a split view available without forcing people into their buzzword AI ML crypto blockchain cloud enabled dev environment nonsense.
Good idea, abysmal execution (which pretty much sums up all of GH these days I suppose).
I admit I don't understand some of the problems mentioned in the article.
E.g. that script that squashes the PR commits together - why would anyone need this, what is wrong with diffing the PR branch and the target branch, using any tool you want?
What forces you to look at the commit history?
I'm perfectly fine with the git CLI and IntellJ for local review work, and Gitlab web UI for the communicative part of a code review.
Only thing I agree with is, I (sometimes) hate the three-way unified diff in IntelliJ for merge/rebase conflicts.
Other times (harmless conflicts), I love it over using the CLI.
Personally, I found the example for the desired diff format confusing.
> For a large change, I don’t want to do a “diff review”, I want to do a proper code review of a codebase at a particular instant in time, paying specific attention to the recently changed areas, but mostly just doing general review, as if I am writing the code. I need to run tests, use goto definition and other editor navigation features, apply local changes to check if some things could have been written differently, look at the wider context to notice things that should have been changed, and in general notice anything that might be not quite right with the codebase, irrespective of the historical path to the current state of the code.
This is spot on. In fact, I think modern code review practices over emphasize the historical path to the code at the expensive of lost quality of the present code and code architecture.
"Minimizing diffs" is a feature of modern code and PR practices, whether it's explicit or tacitly something the developers do. Optimizing for minimizing diffs discourages the continuous refactoring that code bases require to stay solid, sound, and visibly correct.
I put GPT and Llama 70B to write me comments about the Rust language source code. They are both superb at this task. I haven't used any other weaker LLMs in the same fashion, with less billions of parameters, but i can imagine many of them, in the range of 7B to 13B, will perform good enough. I will test more LLMs soon though.
Maybe code reviews on the raw source code, does not need to be confusing anymore. Code reviews on the description of the source code is better.
I tried to prompt the LLM to just summarize the code, and i didn't like the result. The description is indeed verbose and somewhat inefficient.
I tried "write some comments about the source code, in the style of codinghorror" and the results were fantastic.
I am very interested, if someone has found some other styles that work just as well.
Edit: All this to say, that in the space of LLMs and source code, there is a start-up which will be a github disruptor, and a new era of code will begin.
When working on a PR myself, I frequently avoid doing small, incremental commits because I find the subtle "these lines changed" annotations in IDEs extremely useful. It helps me find the locations in code that are relevant to my work.
I wish there was a way to configure e.g., IntelliJ to always show these markers relative to `main` instead of the last commit.
Even though I'm a KDE fan, I usually use Meld for diffing, especially since I've set it up with a lot of custom filters for certain cases. However, when I want to compare 3 different files, kdiff3 is my go-to tool.
looks like the code review is happening too late. here the post’s author is also trying—hard—to reconstruct the mental states and models of the code author, especially in the large/significant update case. i argue that this workflow is a relic of the past, and should be replaced by a two-phase flow where in the beginning the essential ideas of the new changes are proposed, discussed, approved. then lines of code may be added or removed. the update is semantically grouped (perhaps via a commit) to correspond to key decisions made during phase one.
that way the problem of encountering new ideas through the darker medium of code and struggling to comprehend is solved, since now the ideas are presented and evaluated in a human language. the subsequent code review confirms that the implementation adheres to the gaveled proposal, and this can be easily done, even by a junior developer.
This might be a useage thing but author seems to already point out that for a large code review, these two options aren't sufficient, but I've never seen these tools offer themselves as a solution to a large review.
They're a diff tool. The author's approach is creative but seems like it's the wrong tool for the job.
[+] [-] friendzis|2 years ago|reply
obviously every team and ticket is different, but IMO unless the person doing the review is some sort of principal engineer mostly responsible for the code at large, this does not align with I would personally consider a code review. In my book a general code review is simple sanity check by a second pair of eyes, which can result in suggestions to use different API or use an API slightly differently. If commits in the PR are properly ordered/squashed it is relatively easy to review incremental changes in isolation anyway.
I guess the complaint author has is really about review types. I do not have terminology ready at hand, but there is run of the mill sanity check review and then there is deep, architectural feature premerge review. The author complains about the latter when most of the code reviews in web tools are of the former variety.
[+] [-] dylukes|2 years ago|reply
This is an impoverished view of code review. Code review is a principal mechanism for reducing individual code ownership, for propagating conventions, and for skill transfer.
A good code review starts with a good PR: one that outlines what its goals were and how it achieved them.
First item on a good review then: does the code achieve what it set out to do per the outline?
Second: does it contain tests that validate the claimed functionality?
Third: does it respect the architectural conventions of the system so far?
Fourth: is the style in line with expectations?
Fifth, and finally: do you have any suggestions as to better API usage?
A code review that is nothing more than a sanity check is useless and could have been done by CI infrastructure. Code review is a human process and should maximally take advantage of the things only humans could do. Leave the rest to machines.
An implicit question in several of the above is "will this set a good example for future contributions?"
[+] [-] lapcat|2 years ago|reply
Call me crazy, but I've always approached code review from the standpoint of a tester: I build and run the code, see whether it does what it's supposed to do, look for possible weak points, and try to break it.
The diffs are the beginning rather than the end. They show you where to start poking around in the code. The proof is in the pudding, though.
You might respond, "That's what testers are for, not engineers." But who can test better than someone who understands the code and knows exactly where to look and what to look for?
I know this attitude puts me in the minority. The majority of engineers seem to have an inborn horror at the prospect of, gasp, manually running code. (They're also strangely averse to using debuggers.) They'll do anything in the world and write vast infrastructure to avoid it. Automate all the things! But in my view, automation is just more possibly buggy code. Who tests the tests? Quis custodiet ipsos custodes?
[+] [-] lvncelot|2 years ago|reply
A code review is the "last line of defense" (well, disregarding CI), but in the teams I've worked in, that meant that the general idea of what the PR is introducing has been discussed by multiple people at that point. (This could be either a pairing session, an in-depth explanation, or just a coffee chat, depending on the complexity) This way the PR isn't about reviewing the general strategy (splitting off a new module, introducing a huge dependency, reworking the API surface), but just about reviewing the tactics used to implement that strategy.
Without the communication beforehand, doing only sanity checks on parts of the code in isolation does run the risk of fracturing code ownership. ("What's that module doing?" "Beats me, ask bob")
That all notwithstanding, I like the author's idea of what a diff view should look like, regardless of the "mode" of reviewing.
[+] [-] jerf|2 years ago|reply
I push through and do it anyhow, because this is one of those "they're not paying me to have an endless party" sort of things. But I completely 100% agree with the author that it is not a very useful view.
[+] [-] codemac|2 years ago|reply
By not having a basic process for defects, features, etc, every engineer has to make up and invent the process for how they will ship their feature through collaboration.
In most cases this ends up with doing little to nothing, with code review being the only form of collaboration on the topic that is in any meaningful detail. So we're left trying to stuff all possible interventions into a single moment.
[+] [-] robertlagrant|2 years ago|reply
[+] [-] apocalyptic0n3|2 years ago|reply
I don't necessarily disagree with you, but I don't agree either.
A typical workflow should be:
1. Engineer writes code 2. Engineer does manual and automated testing to verify things work correctly 3. Engineer commits, pushes, and creates a PR/MR 4. CI runs test suite 5. Another Engineer reviews PR/MR 6. Approval causes merge which causes deployment to staging 7. QA 8. UAT 9. Repeat steps 1-8 until everybody is happy
In this, we need to place checks on #1 and #2.
In my eyes, QA and UAT are superficial reviews/sanity checks on #2.
#3 is a check in #1. However, it relies on A) previous engineers implementing good tests and B) the current engineer doing the same. This means trusting people are doing the right things, but a Review implies you don't completely trust that.
#5 is a check on #3 and #1. They're essential. Having a full understanding of what the code looks like is more important in my mind than what was actually changed. The changes don't show how other code is interacting with those changes (which should be, but isn't always, captured by unit tests).
That's why I think the article author's preferred view is ideal. In fact, that's roughly what I work with when reviewing without realizing it (diff in GitLab/GitHub/Sublime Merge, code in JetBrains where most of the review happens).
[+] [-] knubie|2 years ago|reply
[0] https://github.com/Wilfred/difftastic
[+] [-] mega_dean|2 years ago|reply
[+] [-] eviks|2 years ago|reply
[+] [-] videlov|2 years ago|reply
[+] [-] m463|2 years ago|reply
[+] [-] rmwaite|2 years ago|reply
[+] [-] mi_lk|2 years ago|reply
[+] [-] JNRowe|2 years ago|reply
* A little scripting around opening the PR, which basically performs a "vimdiff <(git show baseref:file) file"-style dance on the changes(see :h diff). Using vim's tabs is great for this as they're really only views, so you can hold individual buffers open in distinct states at the same time.
* Scroll locking still works as expected in the main view, but you can avoid it in a separate tab when needed.
* [c and ]c move between hunks from the set of changes as they exist in the PR not in the working directory.
* dp and dg allow you to mark hunks as "done" by pushing/pulling the hunk in to the read-only diff buffer so that they're now hidden from the highlighted changes in the live buffer.
* Changes you make in the live buffer are available to commit directly, or push as a comment.
* All your regular editor things work as expected in the current state of the tree; go to definition, build integration, popup docs, etc.
Working like this means you're viewing changes against the PR's base, but have a clean working directory. That, to me, feels like a significant improvement over matklad's solution of having the working directory be in an unclean state to view the changes.
The environment I work in makes this behaviour super nice as changes will often be added with a --fixup commit, and then the tooling mangles them back together with a git-interpret-trailers call to attribute the fixup commit's author to the original commit at merge time. It also pulls text comments out of the PR and attaches a Reviewed-by trailer where appropriate, or the +1 equivalent to tack an Acked-by trailer on.
[+] [-] kerneis|2 years ago|reply
[+] [-] iot_devs|2 years ago|reply
Code review is hard because the diff always looks reasonable, the tests always pass and all the basic stuff are always checked.
However, it happens often that, even if the changes looks reasonable they are wrong.
The whole architecture may drift after one bad change that looks reasonable.
As always this is not strictly a problem with the tooling, but more of culture and knowledge sharing.
And we are not going to solve it with a better tool.
[+] [-] zmj|2 years ago|reply
> it happens often that, even if the changes looks reasonable they are wrong
I’m having trouble reconciling these two statements.
When I review code, I’m rarely looking for bugs. Instead I’m looking for tests that would catch those bugs.
[+] [-] talent_deprived|2 years ago|reply
[+] [-] lelanthran|2 years ago|reply
His ideal diff is pretty much the same as a split-diff but with redundant context removed (context is only on the left, not on both left and right). What utility does he get out of removing redundant context on the RHS of the pane?
[+] [-] klauserc|2 years ago|reply
> I need to run tests, use goto definition and other editor navigation features, apply local changes to check if some things could have been written differently, look at the wider context to notice things that should have been changed, and in general notice anything that might be not quite right with the codebase, irrespective of the historical path to the current state of the code.
The editors/IDEs I've used usually only offer rudimentary support in diffs (goto defn, but only in the same file; maybe auto-completion, but usually not for newly added items; no refactoring functionality)
[+] [-] friendzis|2 years ago|reply
In my understanding the author wants to flip the diff around: instead of looking at changes themselves, the author wants to look at code and see if there are any associated changes.
The article is light on detail, but my guess would be that author wants to look at code and browse to implementation/callsite to check if appropriate changes are there.
[+] [-] exclipy|2 years ago|reply
The diff highlighting can be surprisingly distracting and it can definitely help readability to turn it off. I certainly do turn it off from time to time in my diff viewer so I can see the code with fresh eyes, but I don't have the option to show the unified diff in a split pane.
[+] [-] phailhaus|2 years ago|reply
[+] [-] flanbiscuit|2 years ago|reply
By the way, this shortcut also works in Gitlab (just tried it)
[+] [-] jtreminio|2 years ago|reply
[+] [-] Offpics|2 years ago|reply
[+] [-] buro9|2 years ago|reply
I also like their 3-way merge capability https://www.perforce.com/manuals/p4merge/Content/P4Merge/dif...
these features never made it into the web based diff tools that are widespread, I think the 3 way diff is a be a good way to show result of a difficult merge
[+] [-] jakub_g|2 years ago|reply
This will open VSCode in browser, with the pull request in diff view.
Advantages:
- you see whole files there
- diff algo is different than on github.com, sometimes more readable for complex diffs
[+] [-] inferiorhuman|2 years ago|reply
* S-L-O-W
* Glitchy
Which is a travesty because a side by side diff view with an out-of-line list of PR comments could be incredibly useful if it didn't involve spinning up a whole VSCode instance in the browser. In fact it's so useful that GH used to have a split view available without forcing people into their buzzword AI ML crypto blockchain cloud enabled dev environment nonsense.
Good idea, abysmal execution (which pretty much sums up all of GH these days I suppose).
[+] [-] vasergen|2 years ago|reply
[+] [-] jessekv|2 years ago|reply
https://meldmerge.org/
[+] [-] ktpsns|2 years ago|reply
[+] [-] bsimpson|2 years ago|reply
[+] [-] yboris|2 years ago|reply
https://www.npmjs.com/package/diff2html-cli
See the diff as HTML (side by side or unified)
[+] [-] moritzwarhier|2 years ago|reply
E.g. that script that squashes the PR commits together - why would anyone need this, what is wrong with diffing the PR branch and the target branch, using any tool you want?
What forces you to look at the commit history?
I'm perfectly fine with the git CLI and IntellJ for local review work, and Gitlab web UI for the communicative part of a code review.
Only thing I agree with is, I (sometimes) hate the three-way unified diff in IntelliJ for merge/rebase conflicts. Other times (harmless conflicts), I love it over using the CLI.
Personally, I found the example for the desired diff format confusing.
I prefer split to unified diffs though.
[+] [-] password4321|2 years ago|reply
It appears to enable choosing between unified and split views for each of those tools.
[+] [-] nh2|2 years ago|reply
https://github.com/dandavison/delta/issues/535
Difftastic now has JSON output, whic should make it much easier to build this.
[+] [-] avgcorrection|2 years ago|reply
Maybe us plebs just use the diff viewer (or GitHub or) and the IDE/editor/terminal as separate applications.
[+] [-] wellpast|2 years ago|reply
This is spot on. In fact, I think modern code review practices over emphasize the historical path to the code at the expensive of lost quality of the present code and code architecture.
"Minimizing diffs" is a feature of modern code and PR practices, whether it's explicit or tacitly something the developers do. Optimizing for minimizing diffs discourages the continuous refactoring that code bases require to stay solid, sound, and visibly correct.
[+] [-] btbuildem|2 years ago|reply
It seems to me it misses the mark a little -- the text is so verbose, it's easier to read the code itself.
[+] [-] emporas|2 years ago|reply
Maybe code reviews on the raw source code, does not need to be confusing anymore. Code reviews on the description of the source code is better.
I tried to prompt the LLM to just summarize the code, and i didn't like the result. The description is indeed verbose and somewhat inefficient.
I tried "write some comments about the source code, in the style of codinghorror" and the results were fantastic.
I am very interested, if someone has found some other styles that work just as well.
Edit: All this to say, that in the space of LLMs and source code, there is a start-up which will be a github disruptor, and a new era of code will begin.
[+] [-] klauserc|2 years ago|reply
When working on a PR myself, I frequently avoid doing small, incremental commits because I find the subtle "these lines changed" annotations in IDEs extremely useful. It helps me find the locations in code that are relevant to my work.
I wish there was a way to configure e.g., IntelliJ to always show these markers relative to `main` instead of the last commit.
[+] [-] teddyh|2 years ago|reply
[+] [-] shiroiuma|2 years ago|reply
[+] [-] e12e|2 years ago|reply
https://github.com/matklad/config/blob/master/xtool/src/gpr....
[+] [-] gpvos|2 years ago|reply
[+] [-] yawboakye|2 years ago|reply
that way the problem of encountering new ideas through the darker medium of code and struggling to comprehend is solved, since now the ideas are presented and evaluated in a human language. the subsequent code review confirms that the implementation adheres to the gaveled proposal, and this can be easily done, even by a junior developer.
[+] [-] bilekas|2 years ago|reply
They're a diff tool. The author's approach is creative but seems like it's the wrong tool for the job.