Conversation
Tomáš Janoušek
liskin@genserver.social
Edited 14 days ago
I wish someone built a tool for commit-by-commit GitHub pull request reviews.
There's https://github.com/danobi/prr, but it's very basic - just opens the whole PR diff in your text editor and lets you review it as if it had been an email. The workflow I'm envisioning is a bit different though:
* have a keybinding in tig that opens the current commit in my text editor
* store the comments in git notes perhaps (because why not?)
* submit the review comments on individual commits of that PR in GitHub (which can be done manually via the web UI, so surely doable via API too)
#git #github
There's https://github.com/danobi/prr, but it's very basic - just opens the whole PR diff in your text editor and lets you review it as if it had been an email. The workflow I'm envisioning is a bit different though:
* have a keybinding in tig that opens the current commit in my text editor
* store the comments in git notes perhaps (because why not?)
* submit the review comments on individual commits of that PR in GitHub (which can be done manually via the web UI, so surely doable via API too)
#git #github
1
0
0
Jarkko Sakkinen
jarkko
@liskin someone should productize "mailhub" and base it on the first class user experience of kernel.org (vger + lore + patchwork) and cli tools (b4, lei). only email can take most and best out of git :-)
even for low-traffic early phase project where i'm mostly talking to myself i get a lot from this as i can search and timeline my mumblings :-) https://lore.kernel.org/tpm-protocol/
at github i feel as i was suffering from artificial dementia. you don't have "history" at github
even for low-traffic early phase project where i'm mostly talking to myself i get a lot from this as i can search and timeline my mumblings :-) https://lore.kernel.org/tpm-protocol/
at github i feel as i was suffering from artificial dementia. you don't have "history" at github
1
0
1
@jarkko I feel that it shouldn't be impossible to extend GitHub to provide this experience.
Nothing stopping them from having an mbox http endpoint for each PR, and for the whole repo. Well except maybe perf concerns (AI bots hitting the repo-wide mbox every second). And then per-commit reviews are almost there already — the only missing bit is being unable to comment on the commit message itself.
The value I get out of GitHub is mainly being able to collaborate with normies. You can't get normies to run IRC client 24/7, and you can't get normies to git over email. It's just not possible.
Also, I absolutely hate patch emails. Having each patch be an actual git commit with parents and everything is immensely valuable.
Nothing stopping them from having an mbox http endpoint for each PR, and for the whole repo. Well except maybe perf concerns (AI bots hitting the repo-wide mbox every second). And then per-commit reviews are almost there already — the only missing bit is being unable to comment on the commit message itself.
The value I get out of GitHub is mainly being able to collaborate with normies. You can't get normies to run IRC client 24/7, and you can't get normies to git over email. It's just not possible.
Also, I absolutely hate patch emails. Having each patch be an actual git commit with parents and everything is immensely valuable.
1
0
1
Tomáš Janoušek
liskin@genserver.social
@jarkko Oh and also, patch series revisions. GitHub has the whole history of force pushes, but no nice UI to do range-diffs between them. But one can still do it manually by fetching the commit shas that the pull request overview shows. Or, if you're lucky to have git remote updated (fetched) frequently enough, just look at the reflog of the remote branch.
(And then obviously using https://work.lisk.in/2023/10/19/side-by-side-git-range-diff.html to look at said range-diffs 😏)
(And then obviously using https://work.lisk.in/2023/10/19/side-by-side-git-range-diff.html to look at said range-diffs 😏)
1
0
1
Jarkko Sakkinen
jarkko
@liskin kernel.org "Normies" are like the main filter how i deploy my projects :-)
E.g., in this recent tpm2-protocol i use mailing list partly because i want purposely rise the barrier for contributions. However, tpm2sh is at Github in order to "build the following", market the technological advantages to projects such as Himmeblau (Intune integration from the people who deliver us Samba) and perhaps even get contributors for the actual tech project :-)
E.g., in this recent tpm2-protocol i use mailing list partly because i want purposely rise the barrier for contributions. However, tpm2sh is at Github in order to "build the following", market the technological advantages to projects such as Himmeblau (Intune integration from the people who deliver us Samba) and perhaps even get contributors for the actual tech project :-)
1
0
0
Tomáš Janoušek
liskin@genserver.social
@jarkko I wish I was in a position to do the same. Instead I'm a wageslave at corpo so I can afford to live in a high cost-of-living area that I love. And that means GitHub and low-quality contributions that I can only push back against a little bit in a very civilised and friendly manner :-/
tradeoffs in life…
tradeoffs in life…
2
0
1
