I'm definitely intend to add various features that involving getting data from git servers such as, browsing files, viewing commits, overlaying patch comments against code in the main branch tip
What is OOTB?
The server supports CORS everywhere, so it should be possible to clone repos in the browser, which is something I wanted to do in https://patch34.pages.dev, but would be happy to leave it for you on https://gitworkshop.dev
Should be possible using either https://github.com/petersalomonsen/wasm-git or https://github.com/isomorphic-git/isomorphic-git
Discussion
I certainly wouldn't wasn't to discourage anyone from adding similar features to other clients. code collaboration over nostr succeeds when clients compete to provide the best UX for their target audience. different clients and different experiences will suit different user groups who may have different needs
it's been more than a few months since I looked at this aspect but I think I found a way of lazy loading the required data without having to clone. even a depth 1 clone can be bandwidth and storage heavy for many repositories. I'll let you know how I get on.
I think I need to be slapped in the face. I added support for displaying the readme but only for github right now. I planned to use `git archive` but wasm-git and isomorphicgit don't support it. any form of `git clone` is too bandwidth inefficient. I'm not sure its worth prioritising adding another backend proxy (other than though sveltekit) to use the standard git client to achieve this at this point. The other option is identifying the git server software used and targeting the readme's 'raw' url like I'm doing with github.
All I wanted was that people could use self-hosted or niche git servers without having to feel like they were leaving a lot behind on GitHub, but now you're making GitHub the standard again.
Not a big deal, but meh.
Why is git clone inefficient?
Yeah it leave a bad taste in my mouth too. I'm not sure its a good idea to have a better experience for people who are using github as the git server. Its contrary to the philosophy of the project. Maybe I should just pull the feature until it can be supported no matter the git server.
why is git clone inefficent? to display a readme we need to download potentially thousands of commits and (I think) all the files present in the tip of the master branch. with `git archive --remote
Interesting, I didn't know. Apparently neither GitHub nor GitLab support it, which is ridiculous.
Wait, no, it's my git command that is broken? Whenever I try it says
"fatal: operation not supported by protocol"
that means its turned off on the git server end
Do you know of any server that has it working? I'm trying to implement it on https://git.fiatjaf.com/song but git is not even hitting my server when I try it.
I'm not sure `git archive` is a workable solution because daemon.uploadarch needs to be set to true and it is false by default.
It is better to use that than to come up with a different new way of doing things. But so far it is looking like a broken feature in the git client directly that no one uses. It would still be a good idea to fix it and use it than to create a new one.
its definitely worth supporting for git servers designed to work with nostr. Its just widespread support is probably unlikely. Its a little but uncertain the extent to which repositories that use nostr will use free-to-host git servers (ie remain on github) vs using bespoke solutions like song or ghole.
I did some tests with native git options if `git archive`. Its probably then worth having a stateful proxy service that serves from a cache of repositories.
```
git clone --no-checkout --filter=tree:0 https://github.com/bitcoin/bitcoin
cd bitcoin
git restore --staged README.md
git checkout README.md
```
3 calls - 28.44mb + 88kb + 1.57kb
```
git clone --no-checkout --filter=blob:none https://github.com/bitcoin/bitcoin
cd bitcoin
git restore --staged README.md
git checkout README.md
```
2 calls - 55.46mb + 1.57kb
```
git clone --no-checkout
cd bitcoin
git restore --staged README.md
git checkout README.md
```
1 calls - 247.66mb
Its probably a much better UX to enable browsing of directories, files and commits / branches and states at different commit histories. In which case you would need to do some sort of a clone anyway.
By the way, I had some face-to-face conversations with quite a few bitcoin core contributors last week about git over nostr.
They seemed overwhelmingly positive and very aware of the need.
They were very clear that merge commits and maintaining commit ids are an important part of their workflow so the effort I made to enable that through nip34 doesn't seem wasted.
Ideas they came up with to move things forward were:
1) using git over nostr on a sub project such as c-make (probably not this project but maybe something similar). Work is done within a forked repository and changes are periodically pushed to a open PR. The fork could use git over nostr without effecting the rest of bitcoin core.
2) a 2 way bridge to enable contributors to opt-in to using the tools whilst still participating with those on github.
I now have this working for self-hosted gitea, forgejo and gitlab instances. Also for many hosted solutions eg bitbucket.org, sourcehut and lauchpad.net. It turns out that a lot of services redirect https://domain/repo/raw/HEAD/README.md to the raw file with CORS enabled.