71–80 of 124 posts
With this MS acquisition, that proposition is starting to become a problem and an uncool dependancy on MS.
Somewhat related, I've been thinking of how to speed up git on hosts with limited resources. As an example, the firefox repo has a 275MB index file which has to be loaded whenever you want to read the repository. On a host with 1GB of ram this doesn't work so well. I think that storing repositories in loose format would make them much faster to read, but maybe I'm missing something. Any thoughts?
When you say 'read the repo', it makes me think you're more interested in the behaviour of cloning from a remote.
Loose objects would avoid the need to inspect packfiles, but… that code's all written in C and mmaps the contents & does fast seeks. Most likely the slow parts are reconstituting objects from packs (also mmapped C with fast seeks) or delta-compressing objects for git-upload-pack to send to clients. Going to loose objects doesn't help if the remote still burns CPU creating a pack: try using a dumb remote instead of a smart one? You're trading CPU for network now.
If you're more interested in improving performance in a clone: loose objects avoids the need to (fast mmapped C) read a packfile. The index still has to track if you've changed any checked-out file in the working directory, and if there are a lot of files, it's going to be big.
Is there a hosted version of Gitea? Would it be possible to host it and offer unlimited repos for let's say $5/mo as a service?
Plus storage, sure
Earlier quoted context omitted.
For which they need a number of central servers. These server do not do anything with the content, but they serve to announce to any new client what other clients are there, so that these new clients can start setting up their network. Once that's done, the new clients can discover the other nodes through the nodes they just connected to, and the servers have done their job. But the servers are necessary, as far as I…
You are mistaken. DHT is decentralized. https://en.wikipedia.org/wiki/Distributed_hash_table
In theory, yes, if they go down, you could configure your client to point at another well-known client, though.
There are still plenty of things you might want centralized on a server somewhere, but it seems like a lot of the value add of GitHub, GitLab, and now Gitea is in making git repos easier to manage and interact with.
It's interesting to think about how far you could decentralize that, ideally with a "cambrian explosion"[1] of OSS and indie-software clients.
Earlier quoted context omitted.
I agree, additionally git has a built in server for sharing repos over the network. What I'd personally like to see is a repo viewer similar to Github but implemented purely in JavaScript and cloning repos in the fly just like the native git does. Git.js ( https://github.com/yonran/git.js ) has something like that but it looks old and ugly.
What is this built in server git has? I thought sharing git repos over a network was depending on OpenSSH or similar.
Earlier quoted context omitted.
I agree, additionally git has a built in server for sharing repos over the network. What I'd personally like to see is a repo viewer similar to Github but implemented purely in JavaScript and cloning repos in the fly just like the native git does. Git.js ( https://github.com/yonran/git.js ) has something like that but it looks old and ugly.
What is this built in server git has? I thought sharing git repos over a network was depending on OpenSSH or similar.
- https://news.ycombinator.com/item?id=17006503 (has a lot on why it was forked from Gogs and whether using the fork is still a good idea)