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.

Reply to this note

Please Login to reply.

Discussion

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.