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.
