DanConwayDev on Nostr: Yes. two approaches: 1. git's `iterdiff` could be used to generate this within ngit ...
Yes. two approaches:
1. git's `iterdiff` could be used to generate this within ngit and submit it as part of the cover letter (if one is included). There is too much duplication here and there is no garentee that PRs will include this as they may be generated by other tools.
2. apply the patch and output the diff. this could either be done in browser or by a proxy. Ideologically I don't like the idea of being overly reliant on a proxy as I think reliance on back-end infrastructure reduces the simplicity, robustness, and censorship resistance nature of a client. It looks likely that gitworkshop.dev will do a *shallow clone in the browser to deliver files and other git information. Experimentation is needed to see if PRs can be applied without checking out (and downloading) just the reliant files to the PR rather than all files in the latest state. Otherwise this could be bandwidth intensive for the user. Another possibility I have been thinking about is having nostr specific git implementations (like song) apply PRs submitted so the commits could be downloaded via the efficient git protocol and potentially could be used to access the PR diff in a bandwidth efficient way.
Ultimately it would be ideal if we could do approach 2 with everything done in a bandwidth efficient way in the browser.
*for context see
1. git's `iterdiff` could be used to generate this within ngit and submit it as part of the cover letter (if one is included). There is too much duplication here and there is no garentee that PRs will include this as they may be generated by other tools.
2. apply the patch and output the diff. this could either be done in browser or by a proxy. Ideologically I don't like the idea of being overly reliant on a proxy as I think reliance on back-end infrastructure reduces the simplicity, robustness, and censorship resistance nature of a client. It looks likely that gitworkshop.dev will do a *shallow clone in the browser to deliver files and other git information. Experimentation is needed to see if PRs can be applied without checking out (and downloading) just the reliant files to the PR rather than all files in the latest state. Otherwise this could be bandwidth intensive for the user. Another possibility I have been thinking about is having nostr specific git implementations (like song) apply PRs submitted so the commits could be downloaded via the efficient git protocol and potentially could be used to access the PR diff in a bandwidth efficient way.
Ultimately it would be ideal if we could do approach 2 with everything done in a bandwidth efficient way in the browser.
*for context see
quoting nevent1q…xv0dREADME not rendering
I'm not seeing my README.md on the landing page: https://gitworkshop.dev/r/naddr1qqxxjmnnw3skymr0wdek7mgpp4mhxue69uhkummn9ekx7mqzyzrgt6l0vefn3htfx83veheur8vlpedpqe7frrezuuypcf2clra0sqcyqqq80xg9sng4n