I think I have a pretty good developer env going on, but I’m always looking for more things I haven’t thought of.
So does anybody have any uber useful, or fun, or just a general favorite shell/terminal setup or tool?
I think I have a pretty good developer env going on, but I’m always looking for more things I haven’t thought of.
So does anybody have any uber useful, or fun, or just a general favorite shell/terminal setup or tool?
As someone who peddles in email patches from time to time (guix, org-mode), I can tell you that PR’s are far more intuitive: there’s no ambiguity in which branch to apply the diff on, the order of diffs is implicit, and it is far easier to comment.
Email patches are fine, but can be nightmare if you’ve waited too long and the dev branch has changed and the patches are no longer valid, or worse, the author reset the numbering so its not clear what needs to be applied where.
Which is why I said there is clear room for UX improvement—the flow itself is fine. Not that patches or pulls are really that different (where like Bcachefs sends pull requests to the Linux Kernel mailing list), but the UX between these flow is what is the real separator. Patches flows are don’t get your code blocked in review since patches are nebulous things in the æther not tied to branch or anything so I get what you are saying.
In the same sense the UX for PRs (from a web UI as most ‘know’ it) leads to folks either pushing bad history with ‘fix X for review’ commits or rebases that fix this history but none of the big forges show a good UX for these version & make the reviewer feel they need to re-review—or worse maintainers employing a squash–merge process which fixes the useless fix commits but destroy a good history into a single commit. …Where stacked flows like Gerrit do not destroy this history (rebasing fixes are expected with UI showing it) & doesn’t block on review phase.