What is "a gpr script"? It looks like a small rust file that presumably compile to binary custom utility?
https://github.com/matklad/config/blob/master/xtool/src/gpr....
Unified versus Split Diff
91–100 of 184 posts
Re: Unified versus Split Diff
#92I do all my large code reviews in IntelliJ. Seems like it's an exact match of what this guy wants? Diff view + full view + fully featured IDE for all his navigation, verification and search needs
Would be great, but it needs integration. In my case there is no such thing for bitbucket server.
Re: Unified versus Split Diff
#93Earlier quoted context omitted.
Thank you for sharing this project! I have been searching for something like this for some time
I also wonder if it's possible to go beyond this project and have git itself work on the syntax level instead of pure text.
Git doesn't store diffs on logical level. Git operates on snapshots of trees. Commit is not "a collection of changes", it's a snapshot of a tree with attached predecessor of it.
Then the another layer (which can be git, but also can be any other tool, adding custom diff tool to git is very easy) uses that to generate diffs.
There is zero stopping anyone from adding contextual diffs to Git. Just ask it for content of both commits and feed it to the algorithm.
Yes, git underneath stores data as diffs but they are only vaguely related to logical structure of commits
Re: Unified versus Split Diff
#94Earlier quoted context omitted.
In this kind of context, I ask people what log level they'd like their review at. If you just want to get the code out the door, by all means, "error" or "warn" might be the right review depth, when you're confident in your code and don't want to be derailed with philosophy. If you're exploring a new concept and want all the ideas and brainstorming you can get in your feedback, "debug" log level is appropriate. Once…
> In this kind of context, I ask people what log level they'd like their review at. It's a code review, not a QA session.
Isn’t QA the whole point of code review?
Re: Unified versus Split Diff
#95Earlier quoted context omitted.
Thank you for sharing this project! I have been searching for something like this for some time
I also wonder if it's possible to go beyond this project and have git itself work on the syntax level instead of pure text.
I feel it is best to leave git out of this - separation of concerns
Let external tools evolve independently instead.
Re: Unified versus Split Diff
#96If 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.
This is game changing, thank you for telling us this.
Re: Unified versus Split Diff
#97Semi-related, I recently discovered https://github.com/dandavison/delta: A syntax-highlighting pager for git, diff, and grep output
It appears to enable choosing between unified and split views for each of those tools.
Re: Unified versus Split Diff
#98Earlier quoted context omitted.
> 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 goa…
I go back and forth on this. On the one hand, I really like constant deep feedback. I really like the consistency benefits of having another person say “that’s too much, I find that unreadable.” On the other, I have now been at a lot of places where it was very hard to get my code reviewed, latencies of days and sometimes weeks if folks are in a particularly heinous crunchtime... And then when it does get reviewed, t…
I'm a principal so I rarely write code now. I probably do 6 PRs a year, basically when its directly related to my expertise and it makes more sense for me to do it. But when I do, I really try to guide the reviewer into my thought process. In your "centralize cache invalidation", I would have in the PR (and probably as comments in the code too) "I moved the cache invalidation to this function to centralizes the logic, it avoids problems X, Y, and Z which we've seen before".
I find that giving a good narrative gets the reviewer thinking like you or at least tells them why you chose one path and not another so that they don't waste time with a "why didn't you do it this way" question.
I keep trying to train my team do to that, but they're so focused on completing tickets they don't want to take the extra time to explain their "whys" and thought processes.
Re: Unified versus Split Diff
#99Neat, I also far prefer using in-editor staging & commiting workflows which are excellent by necessity; history tools by comparison are weak unless I'm missing something. So this seems really useful.
I might reuse the pattern to step through tutorial-type developments directly in-editor for presentations and videos.
Re: Unified versus Split Diff
#100Earlier quoted context omitted.
> In this kind of context, I ask people what log level they'd like their review at. It's a code review, not a QA session.
Isn’t QA the whole point of code review?
Code review is part of the QA but code review is code review. Tell me everything what you see, don't selectively skip things.