31–40 of 184 posts
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
* A little scripting around opening the PR, which basically performs a "vimdiff 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.
Earlier 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 too find that its basically impossible to suggest switching to this workflow, given the weight of all our existing tools. They are so easy to setup, and most come for free (Azure Devops/Pipelines thing) that going off the track is just unthinkable.
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.
Maybe us plebs just use the diff viewer (or GitHub or) and the IDE/editor/terminal as separate applications.
Earlier 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…
As I have said - every team is different :) In response to your first point I guess things really depend on where you store PR metadata and how ephemeral/permanent it is. Some teams store that information in the ticket, some fill implementation notes with change request, some add that to the PR, some discuss in their standup (or similar) meeting. Regarding 2-3, you are right, I just lumped them all under umbrella ter…
OP is right though, if the "check out in editor" workflow was much smoother (than quick web view) I would prefer to always do that
Earlier quoted context omitted.
As a counterpoint, individual code ownership can be a fantastic model too. It lets engineers specialize and takes advantage of social systems that form naturally anyways. I’ve not personally seen group ownership work well, and in practice, it’s still an individual who knows a given area the best.
> reducing individual code ownership I am now working in an organization that is set up to reduce code ownership, and they struggle to attract talent, although pay is good and work is fulfilling. How do they do reduce individual code ownership? Horizontal integration. Developers code, analysts design DB structures (at least nominally), project managers set up meetings. Different silos exist for CICD, cloud roles, cor…
These might not be related though?
> work is fulfilling
> It exhilarating to start projects, then see them degrade inevitably into corporate monstrosities.
What you describe does not sound pleasant. So it's not fulfilling after all?
FYI if using GitHub, on github.com pull request page, press `.`, or change domain name to github.dev. 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
A third (fourth?) option worth mentioning here is difftastic[0], which uses "structural" diffing (as opposed to line diffing) for more granular diff highlighting. [0] https://github.com/Wilfred/difftastic