61–70 of 124 posts
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?
Does Gitea still not have a good mechanism for backup and restore? I wanted to move away from Gogs but this is a show stopper for me.
Git is a distributed version control system. Every repo can be the master repo. 'Master' is purely a function of convention. It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design. Tools like this primarily provide a web client to a repository not intended as a working copy, with some optional non-git code collaboration tools, such as issues, and an inbox of p…
In retrospect I think it makes complete sense to tie code, documentation and issues. They evolve together, maybe they ought to be versioned together.
Earlier quoted context omitted.
> It does cost money to host these type of applications I'm hosting Gitea (together with around 10 other services) on a 1/1 instance (1 CPU, 1 GB RAM) at Hetzner. Those can be had for € 2,50 per month. > its easier to have contributions on GitHub since it doesn't require most people to register a new account That's the big issue.
> I'm hosting Gitea (together with around 10 other services) on a 1/1 instance (1 CPU, 1 GB RAM) at Hetzner. Those can be had for € 2,50 per month. But can the Gitea devs scale it to support potential growth that costs beyond $10 a month? This is the reality too.
Git is a distributed version control system. Every repo can be the master repo. 'Master' is purely a function of convention. It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design. Tools like this primarily provide a web client to a repository not intended as a working copy, with some optional non-git code collaboration tools, such as issues, and an inbox of p…
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.
Earlier quoted context omitted.
> It does cost money to host these type of applications I'm hosting Gitea (together with around 10 other services) on a 1/1 instance (1 CPU, 1 GB RAM) at Hetzner. Those can be had for € 2,50 per month. > its easier to have contributions on GitHub since it doesn't require most people to register a new account That's the big issue.
> I'm hosting Gitea (together with around 10 other services) on a 1/1 instance (1 CPU, 1 GB RAM) at Hetzner. Those can be had for € 2,50 per month. But can the Gitea devs scale it to support potential growth that costs beyond $10 a month? This is the reality too.
Earlier quoted context omitted.
Aren't torrents using DHT?
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…
Earlier quoted context omitted.
For the vast majority of use cases centralization is an essential feature. You want that single source of truth, then you can have tons of branches etc. outside but without that single source everything falls apart if you are a team of more than one person. I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my wo…
AFAIK the Linux Kernel doesn't have a single source of truth.
Linux kernel dev branch single source of truth is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
The stable branches have their single source of truth repositories, too.
Earlier quoted context omitted.
For the vast majority of use cases centralization is an essential feature. You want that single source of truth, then you can have tons of branches etc. outside but without that single source everything falls apart if you are a team of more than one person. I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my wo…
AFAIK the Linux Kernel doesn't have a single source of truth.
Of course some (many) people are using forks, but all sync directly or indirectly with this dude's version.
Git is a distributed version control system. Every repo can be the master repo. 'Master' is purely a function of convention. It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design. Tools like this primarily provide a web client to a repository not intended as a working copy, with some optional non-git code collaboration tools, such as issues, and an inbox of p…
The more I think about it the more I think Fossil[1] has the right approach by bundling bug tracking and wiki within the VCS. If git did the same thing (and the tools were usable) then nobody would worry about github "going bad" or anything like that. Changing your host would be as simple as changing your 'origin', anybody could replicate all the information easily. When I first heard about Fossil it sounded a bit li…