51–60 of 124 posts
I think that storing repositories in loose format would make them much faster to read, but maybe I'm missing something. Any thoughts?
Earlier quoted context omitted.
See https://github.com/go-gitea/gitea/issues/1029 - self hosting as almost there.
An insightful comment linked to from that issue: https://lobste.rs/s/gokjbo/gitea_1_1_0_released#c_dg9pwe
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…
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.
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…
Heck even torrents which are distributed needed a central server to connect through for ages. There's definitely a benefit to having a central server that aids the sea of clients / servers to communicate.
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…
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…
Isn't that just a straw man argument?
To the extent that it applies to distributed version control, it seems like an invented problem (i.e. I don't know anyone who uses a dvcs that pulls from 'random' developers). To the extent that it is true (we are all probably guilty of using code from developers we don't know and have not properly vetted) i t seems like just as much---if not more of a problem---with github-esque projects.
> I often get the impression that what they really love is local commits
That's a really good point I have not considered before. So would you say that git's main contribution to the development community is showing the power of a VCS with local commits? And that's why github is dominating core git?
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…
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…
Earlier quoted context omitted.
Independent of Gitea (which I have nothing to do with nor have any relationship with anyone involved). Your comment "It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design." worries me. Yes, technically accurate, just as notepad, webstorm, atom, vi, emacs, etc. also don't need any 'host'. If you aren't working with multiple authors, a local laptop with git plu…
I took the comment as referring to hosting just a git repo on a public server. If you are working on a private project a simple option is to get a cheap VPS, give all your developers user accounts, and clone the repo into a shared folder. Everyone can pull and push with ssh and you can use Trello or whatever for issue tracking. Certainly that doesn't cover every use case, but it's worth being aware of the option and…
Entertainingly the code is hosted on github. :-) I'd have more confidence in it if it could self-host and I was able to see gitea inside of a gitea instance and that was the main workflow. Like this, it feels like maintainers aren't prepared to eat their own dog food just yet. That's fine, but I'll take a pass until that's fixed.
There's some level of irony in a GitHub alternative that's hosted on GitHub.
Earlier quoted context omitted.
Heck even torrents which are distributed needed a central server to connect through for ages. There's definitely a benefit to having a central server that aids the sea of clients / servers to communicate.
Aren't torrents using DHT?
But the servers are necessary, as far as I know, unless you want to enumerate IP addresses and scan for open ports. Which is going to be interesting with IPv6.