But if we can't get the archive stuff to work then we could standardize an HTTP API thing that returns raw files maybe.
Discussion
as you can see the HTTP API thing is a bit of a mess but the most common format is`https://
```typescript
/** most servers will produce a CORS error so a proxy should be used */
export const cloneArrayToReadMeUrls = (clone: string[]): string[] => {
const addresses = clone.map(extractRepoAddress)
/**
* at the time of this commit these urls work for:
* self-hosted gitea (or forgejo), gitlab
* github.com
* bitbucket.org
* gitlab.org
* gitea.com
* codeberg.org (forgejo instance)
* sourcehut (git.sr.ht)
* launchpad.net
* It doesnt work for:
* self-hosted gogs (requires branch name repo/raw/master/README.md)
* sourceforge.net (https://sourceforge.net/p/mingw/catgets/ci/master/tree/README?format=raw)
* notabug.org (requires branch name notabug.org/org/repo/raw/master/README.md)
*/
return [
...addresses.flatMap((address) => {
let prefix = 'raw/HEAD'
if (address.includes('sr.ht')) prefix = 'blob/HEAD'
if (
address.includes('git.launchpad.net') ||
address.includes('git.savannah.gnu.org')
)
prefix = 'plain'
if (address.includes('github.com')) {
// raw.githubusercontent.com can be used without CORS error
address = address.replace('github.com', 'raw.githubusercontent.com')
prefix = 'HEAD'
}
return ['README.md', 'readme.md'].map(
(filename) => `https://${address}/${prefix}/${filename}`
)
}),
]
}
```
I was thinking that exposing files at exact commits would be simpler, but then I realized that to get the exact commit you would need an API that returns all references and HEAD (separate from the repository state event) and then I realized that to build a GitHub-like way to browse files on gitworkshop you'll also need all these things, plus a history of commits, metadata about all commits and so on, right?
Which brings me back to: why not do a full repository clone on the browser and get all that data at once? Is it just the big size of things?
What about doing a `git clone --depth 1`? I don't know how to do that on a JS library in the browser, but should be possible. Seems to be a pure client-side thing since it worked on 'song' (from the CLI) without me having to do anything on the server side.
OK, already answered here: nostr:nevent1qqs8uc0ls5h9tz6kqkmgl04jam4lhrnndnr5jmtdfj8u52nu9wjsqdcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7z8vglz
But is it really that slow? It's hard for me to believe it is that slow since on my terminal it runs so fast!
Anyway, I'll wait for your answer regarding the repository metadata required. I can't see a way around that if you want a nice way to browse through the repo and view things in context. But if the goal is just showing a README then that's much simpler.
We discussed it back in March and here are some numbers for the bitcoin core repo:
tbh those numbers are not that big. last time I checked, git implementations in the browser don't support these advanced flags. doing a full clone automatically in the browser is probably a bad idea as it is unfair on those who are bandwidth constrained.
But this could be done statelessly on a server fairly quickly. bandwidth on a VPS is probably quite cheap these days so if traffic volumes were low it shouldn't be too expensive.
Depending on the bandwidth vs storage costs it could be worth storing a clone of repositories and using that instead. That way it would be easier, or cheaper per interaction, to allow browsing commits, metadata, etc.
From a decentralisation point of view, I could build `ngit serve` which could be used instead (even in offline scenarios) instead of the proxy.
You could have a button to clone and display files, maybe?
What library would you use in the browser to do a clone?
I did
git clone --no-checkout --depth 1 --filter=blob:none https://github.com/bitcoin/bitcoin
and got 216K, ahahah.
O yeah?! I'm at a loss to think how I didn't try that before. This is the way.