121–124 of 124 posts
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.
Earlier quoted context omitted.
A frantic commit free for all isn't necessarily better. I count nine different developers committing to the project's master branch in a single day. That has tradeoffs too.
Comparing commits is mostly pointless anyway. Some people commit very often any little change (like some indentation change) while others commit only when a feature is done. Compare releases and features.
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.
There are some real world problems with that: * Many networks limit access between wireless clients, preventing the connection between develop ER machines. * Host based firewalls often prevent services from listening on client machines. Getting security exceptions for this can be difficult to impossible in some organizations. * Discovery and initial remote config can be painful. While largely trivial from a technical…
Well, actually I wasn't suggesting that, just emphasizing git's distributed nature.
What I do suggest is a federated model, large number of small hosts akin to Mastodon. What would be the real issue is, like you noted, discovery. Centralized solutions have it nicely solved but it's hard to do in general with decentralized ones.