How do those Docker-based CI systems support Windows and Mac builders? Aren't you constrained to just Linux? Seems like quite a crippling constraint in a huge number of situations.
I like it a lot better than NW/Electron that I've used plenty before. Smaller packages and faster startup but way longer build times, which is a bit of a hassle but it's Rust, so not sure you can expect otherwise.
There are still some bugs around that are a bit of a hassle to deal with, but only one that is a showstopper for me personally (the back button on the mouse doesn't navigate back), otherwise it works out well for me.
You get access to the organizations in which the user is, which is really nice to provide access to other company services based on this information.
A small example, we create users for our customers in gitea and they are only part of the "customer" organization. This automatically get them access to the "customer" worklog as they access the customer area. So gitea is for us the central identity management.
No fan of Discord but from what I remember the functionality is opt-in and if the webhook is not configured it does nothing.
Among all the possible things to get worked-up about this seems like nothing (unless you are purist that considers including optional functionality to interface with a proprietary-service to be harmful).
In the beginning after the fork, gitea added features which I didn't need. Nothing against gitea just thought I'd also mention gogs, which hummed along here fine and if possible I prefer the code from the original author. (Edit, mmh, not always true, I use neovim...)
At a company I worked at, for security reasons we used gogs. Boss didn't want some random NPM-downloaded javascript anywhere near our source code, which was something which handled enormous piles of money. Gogs doesn't bother with any nodejs at all.
Personally I like even MORE basic than gogs or gitea and use this at my own company:
I don’t feel that “Git service” is quite doing it justice. If it were just a Git service, I don’t think it’d have the social features: repository namespacing, user accounts (at least to the extent it has them), issue tracking, pull requests, release management, wiki, watching/starring/forking…
Now as it happens, I actively don’t want any of that stuff for something I’m hosting for myself for my own projects only. I pretty much just want the parts you’d get in gitweb or cgit, but done better (since neither of those is very good; I run gitweb because I wasn’t impressed with either, but gitweb was easier to patch into a more acceptable shape). Is Gitea capable of being pared down to just this? Is there anything else that fills this niche?
As regards features, git.sr.ht is certainly lighter than Gitea, but still suffers from various of the same problems because it’s designed to run the show with social operation, rather than just doing read-only publication of repositories that it finds at such-and-such a location. It doesn’t have as much extraneous and undesirable functionality (e.g. no issue tracking), but when setting it up requires PostgreSQL and Redis (which latter I think you may be able to skip, but it’s hard-required in the systemd units I see) and more… yeah, this is not what I’m looking for. Operationally, Gitea is considerably lighter than git.sr.ht, as you can get it going with only Git and SQLite installed.
Sure Gitea does a bit too much for a single individual, but you don't have to use the additional features. Honestly, the UX of gitweb is pretty bad so even if Gitea has too much, it's still better than gitweb. Who knows, maybe someone will clone a Gitea and rip out all the social features from it.
I've been thinking of making Yet Another Git Repo Browser™ from scratch these last couple of years, with features I've been missing in gitweb and with a cleaner/more familiar UI. Maybe it's time to revive that old prototype.
What issues did you have with gitweb? And what stuff did you patch up?
That's not a Git web interface, that's a completely different source control system altogether!
And from a quick bit of web searching, it looks like most IDE's out there either lack a plugin for fossil, or else have a plugin that's outdated and doesn't keep up with the current version of the IDE.
I realize that all of these "I Like X!" silly HN threads invite a lot of "I Like Y!" silly replies, but there sure are a lot of caveats on "better" here. You could make a much stronger case for recommending Subversion or CVS, lol.
yes, thank you.But light and self Hosted version control,I have to recommand fossil.Git is not gods,we can blame it and recommand other more better software for special case.
I found the Auth bit a bit difficult to parse. I wanted to used Firebase for it but didn’t quite know how. How are people handling user registration and SSO?
Not sure about Github but Gitlab does. It just creates a new repo under your account when you push to a non-existing one. Seems like a very basic feature to me.
Not sure if doing it that way will create a private repo or not (at the airport and I can’t check), but you can use the GitHub CLI to do it. I’m a huge fan of the CLI, but obviously being able to do it without that is nice.
I dislike organizations that take open source things like git, and then extend them to add features making them propriety work flow lock in making it hard to move to a new platform
Another company was famous for this, they used to call it Embrace, Extend, Extinguish
Gitlab does, as well as gitolite (which is a very lightweight, repository-only solution without a GUI or any of the fancy features like merge requests but it's perfect for my personal needs. Repo creation on push it the main feature that made me choose it. It is administered through git as well which I think is nice).
been using it for 4+ years, no complains and it keeps getting better. each upgrade is super simple: just stop the service, replace that one single binary, and start the service.
I’ve been running local Gitea for about 4 years. It works great, no complaints here. I mirror my GitHub repos (and sensitive repos I don’t want to trust on GitHub) and back up the hard drives with BackBlaze.
I’ll go against the grain and say, Gitea is good but could use a lot of improvement. We use it at my company (startup) and find there are issues with migrations (up but no down), nonstandard web framework (go-macaron), and far too much logic implemented in go templates. There are also some strange issues with how errors are reported. Go is a fine language, but Gitea isn’t a great Go codebase.
Of course, we/I understand open source software isn’t perfect and such. That isn’t my point, I’m just saying that Gitea could use a complete rewrite, ideally using NextJS (if SSR is that important) or moving most if not all view logic into the client side, ditching go-macaron and xorm for something more widely used, relying less heavily on go templates, and doing error handling a bit better.
That said, Gitea does have a good excuse which is that it inherited many of these things from Gogs, from which it was forked.
I'll go and say a really don't like arrogant comments like yours. Shitting on someone's work you're using for free by recommending complete rewrite in technologies you currently like is absurd. Less used framework - so what. Logic in templates - yeah not great but still, so what? Etc... Doesn't really bother anyone using it.
There’s nothing arrogant in my comment. Like I said, Gitea is good. Like all other software, iterations improve quality, and I’m just saying it’s time for the next iteration. I probably would have written Gitea the exact same way if I were in the developers’ shoes, but that doesn’t mean a rewrite wouldn’t still be in order.
As for the so what, I think the answer is just that things can be better, so if someone is out there reading this thread who has some time, they can see this and know what kind of improvements can be made.
> If it ain't broke don't fix it? Or is there some specific shortcomming that might justify a rewrite?
I’m answering that question. The information is out there, so if people want to ignore it that’s beyond my mandate. But this is still constructive since someone out there wanting to rewrite Gitea will want to know what the pain points are before they do so.
I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice. I’d much rather see it rewritten in Rust, but that’s irrelevant.
SSR is "fine", but it doesn't need to be this painful. Here's an example buggy piece of code:
{{range $i, $file := .Diff.Files}}
<div>
{{ if $file.IsSpecialFile }}
<div>Special file ({{$file.name}})
{{ end }}
</div>
{{end}}
Because of the missing </div>, instead of a list of files, it produces a file listing inside of another file listing inside of another, etc. That's just something you'd never be able to accidentally do in NextJS, or anything that uses JSX-like structure.
Then there are clerical things like where to put styles and presentation logic. Gitea uses a mix between jQuery and Vue, with CSS rules sprinkled in randomly. The result is that by looking at the template and the class names on each element, you have no idea whether a class name or ID is going to have significance to jQuery, CSS, or if it's just dead code. Something like styled-components, and use of a single stack (Next as opposed to jQuery+Vue) eliminates the fear and clerical aspect of development.
It's not just arrogance, it's called being a "modern JS developer". The bubble some of these people are living in is so rigid, they can't simply accept when someone does things differently. Some quotes from the parent are as follows, accompanied with some sarcasm on my end:
> nonstandard web framework (go-macaron)...
The "standard" is React and Vercel offerings. Get with the times.
> ditching go-macaron and xorm for something more widely used...
You're only supposed to use libraries that are #1 popularity in their respective category, few weeks of no commits means the library is dead.
> I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice...
Yes, you read that right. This is the advice for Gitea: Github, Gitlab, SourceHut all used server-side templates, so much so that latter two are quite useful even when JS is disabled- but the "better engineering choice" (citations sorely needed) is NextJS.
> few weeks of no commits means the library is dead.
Xorm is so old and disused, it's been absorbed into Gitea and the Github repo is archived as read-only. You get much better capability out of something that's widely used, that's it. I don't care at all about how "modern" something is, if you can't roll back a migration because of your ORM then you have a nonideal ORM.
> The "standard" is React and Vercel offerings
No, I was thinking Gin or Buffalo. Something that a lot of people use and that's seeing a lot of love, you know... a standard.
> they can't simply accept when someone does things differently.
Yea, that's why I continue to accept Gitea as a good piece of software. Only people who cannot accept software packages as they are go out, call them "good", and try to get people to understand how it can become even better.
I understand how migrations issues could be a problem, but how is the nonstandard web framework and the logic in the templates a problem as a user? Maybe it makes it harder for you to contribute to the project (and probaably for other people), thus slowing down the rate of improvement? Maybe other framework have better performance? Not denying your experience, just curious about the consequences of stuff like go-macaron.
Makes bugs harder to fix/diagnose and new features harder to implement. Yes, there is some UX and performance cost for certain actions if they require a roundtrip to the server. That isn’t my main concern, it’s just the speed of development.
For migrations, if a migration fails, you have no way of rolling it back because they only go up and not down. This is just a specific instance of the problem of having less popular dependencies — the bug fixes and new features are less plentiful because there’s not as wide of a community. That applies to xorm and go-macaron.
Can you show an example of excessive logic in templates? My experience of Go templates is that they're practically impossible to implement any interesting logic in, so that's certainly interesting.
Here's a good sample file. The cyclomatic complexity is through the roof: note the variable assignments, function calls, string concatenation, large number of `if`/`else if`s, nested conditional expressions (line 254). I don't even want to know how many permutations of this page are possible...
I’ve been using gitea for a number of years - before GitHub started letting people have private repos for free it was about the only option for a self hosted private repo with a GUI. It’s written in Go which makes it very convenient to run from a usb stick. It also has a feature to mirror other repos and I use that to keep local copies of projects I follow - and has saved me a couple times when the project authors decided to delete their repos or YouTube decided to not host them. Today I use gitea to host my private development server as a Tor hidden service which makes it easily accessible from almost anywhere - though many major hotels chains will ban your MAC address locally if they see you connecting to Tor servers, but never had issues while at an AirBNB which is where I spend most of my time these days.
I didn’t leave my apartment for two years because of Covid and decided a change of scenery would be nice, so my family and I have been bouncing around rural AirBNBs for about six months. Though we’ll have to go back in another month - my son really wants to go back to in-person schooling, that is starting soon. But back to the woods as soon as he gets tired of high school life!
> as a Tor hidden service which makes it easily accessible from almost anywhere
I have a wireguard with the server running on a small VPS, which is useful for both ignoring filtering on public wifi and getting into my home network from wherever.
I have a similar setup and I was also quite paranoid at first. Wireguard is a very solid solution that does precisely what it claims to do and allows you to layer extra network controls on top of it, so the vpn clients only get routed where you allow them to.
A bit less hands-on solution could be something like tailscale.
The VPS is running sshd (pubkey auth only) and Wireguard, and I also see bound UDP sockets for dhclient and ntpd. And that's it, at least for the public interface.
Also, things I want to look at on my home network mostly work fine over ssh (console stuff, git, etc). So I haven't actually gotten around to setting up full routing yet, and use the wireguard endpoint box as an ssh jumphost / bastion (and can forward ports if I do have something to get at that doesn't like to play nice).
You can lock down a wireguard vpn server pretty hard, because wireguard itself is essentially invisible unless you know it's there. It doesn't respond to anything but well formed, correctly signed (in the case of connection initiation) or encrypted (for the actual network itself) packets. So conceivably, you can have your vpn server not respond to public icmp, not expose even ssh without wireguard under it, and be essentially invisible to the internet.
If you are not replying to ICMP you let everyone know that you are there. If you we're not there, the error would be 'no route to host', but there is a route, so you must bei there
One of the benefits to Tor is you don’t need to open any ports, the Tor acts as a reverse proxy for onion services. A lot of Tor services run over port 443 because it gets passed through with little to no issue. With Wireguard you have to deal with all the networks, particularly airports and businesses, that don’t allow UDP. I’ve had a good bit of luck using the dns and ntp ports for wireguard but if your on a network that has something filtering/monitoring dns or only wants you to use their time server, those can stop you also. Once http/3 is official that should make things better for everyone using wireguard.
Plus tor hidden services -or whatever the current nomenclature is- offer a fairly robust and painless story for authentication in this "sorta VPN" scenario. Generate a couple extra keys and invite a friend and his bots.
I do the client auth feature. The chances of someone stumbling across my hidden service is pretty low I think, but it’s not zero. With auth set up I don’t think a Tor client can even get the Id of the rendezvous server without having the correct key.
I think headscale/ other mesh vpns would be better choices so you can get direct connection to your home instead of passing everything through the VPS.
Yes, that's when it was included to Trac 1.0 as a built-in plugin. Before that, it was a 3rd party plugin you have to install yourself. I remember using it before 2010 and I'm pretty sure the plugin pre-dates github.
Personal choice but indeed Trac is very nice and is still used by high profile projects like Django (especially supporting ticket triage) and Twisted Matrix.
Indeed fossil-scm [1], has same interface as Trac (in my view partly inspired by it). Have used Trac for a long time, so can't complain, it works well, its simple and flexible.
I mean, if we're counting Trac as the same, despite the drastically different UI and project-first rather than code-first focus, then we also need to count Sourceforge, which was open source in its first (2000) and third (2009) incarnations.
Gitlab is great, but it also is pretty resource hungry. I opted for Gitea for that reason, so it would be viable on the cheapest Linode server option, and I've mostly been satisfied with it, thus far.
Same, there were a number of GitHub like services you could self host but gitea stood out to me as the easiest to install and maintain. A lot of the other options I looked at required multiple daemons, a full database, etc. Gitea can use a full database but works great with SQLite also.
Gitea is very easy to use, but I find the Activity feature is a little slow.
I experienced the "Try Gitea" service and migrated our TiDB repo https://github.com/pingcap/tidb to it. When I clicked the Activity tab and selected "1 year" period, I found the page loading was so slow, nearly 90s. And I also found that this Activity doesn't have a Cache, I re-selected "1 year" again, and the page loading was nearly the same time.
I guess Gitea uses git command to traverse all the logs for the period every time. Maybe it can use a database to speed up, or like Github only provide at max "1 month" period.
Could just be because the "Try Gitea" service is just a test deployment, staging environment if you will. I don't think it's optimized in any way at all.
Trying to same on Codeberg, which is a production environment of Gitea, the loading time of the "Activity" page for Codeberg/gitea seems to take ~5 seconds for me. It still seems to lack any sort of caching, but at least it's relatively fast. See https://codeberg.org/Codeberg/gitea/activity/yearly (people might want to be careful hitting that URL over-and-over, in case we ddos the Codeberg folks :/ )
It would be generally be a good idea to migrate away from this to something else, I use gitbucket, and it works very well for me.
Yes it is an open source project, but the entire team that works on it is based out in China, and that's really not something you want to play games with.
Has there been any issues because of that, or is this just speculation on your part? The codebase is open source so it's not like they can hide anything.
It's not so much about the issues, but the potential for issues down the line.
For tools like this the aim is always to lay low and expand to reach as far as possible, then once you have a lot of control and trust you can abuse it, often you can abuse it without much loss, because once you have institutional momentum it's very hard to screw it up.
You can't operate on If there's a history of abuse of power, only if there is an incentive. I believe there's a very strong incentive in this case.
All you need to do is sneak in something in an update that gives people access to your server, or creates a vulnerability that allows them to get access.
The fact that itself hosted is actually a really huge concern, because this thing is sitting on your local network with no firewall between it and everything else that you run.
It takes very little to put a vulnerability in a piece of code, and unless you have a person combing every commit with a fine tooth comb, even the fact that it's open source cannot prevent that.
No single security measure is bulletproof. Being open source does not counteract the misaligned incentives.
I am no Sinophobe but I think the pragmatic concern is by being under P.R.C jurisdiction 'certain parties' could either force abandonment of the project by (some of) the original team or compel certain code changes that may not be in the users interest.
No offense to anyone and do not want to imply anything nefarious is about but from what I remember Gogs was even worse in that only a single maintainer inside P.R.C had merge access to the main branch. Also a concern because I might remember something about known vulnerabilities having been outstanding on the issue-tracker when the maintainer was busy.
In that vein, as a European I'm generally more afraid of US. How they can force anyone to give up my secrets. Or the power of Google, MS, Facebook to screw me over.
> Yes it is an open source project, but the entire team that works on it is based out in China, and that's really not something you want to play games with.
China is a country that has been well well known for theft of intellectual property for a couple of decades now, and when the majority of the people developing the project live inside of the borders of China their state has an incredible ability to control the direction of the project and sneak in bad changes over time should they want to.
The fact that it's open source helps a little bit, but I do not believe they number of eyes on the project is enough that they couldn't sneak something through if they wanted to. This isn't Linux with worldwide attention, it's a relative niche.
If it's the entire team or not doesn't really matter, what matters is is that the locus of control, the people who really own the project and commit most of the changes are all based in China.
But you are correct, they do get commits from outside of the country
Is it possible to hide users listing[1] on Gitea via configuration?
On Gogs it's not configurable and to stop publishing names of all users, including admin account username, it's necessary to either close down the whole service (disable public view of all repos and disable signup) or block certain addresses on proxy level.
edit: to clarify. It’s fine for a one man show or a small company. Once you get bigger, you start hitting the various issues quite often, and wish for github again.
I've enjoyed using git-ssb (https://scuttlebot.io/apis/community/git-ssb.html), which allows me to save and share git repos using the scuttlebutt gossip protocol. Makes for a nice decentralized solution where I can back up between my machines, and those that I'm working on a project with.
The only problem that I've found is that my github repo now shows very little activity which make job hunting harder.
I have some personal projects on my own public git server that hardly anyone knows about but I still have a second remote for that stuff which goes on my github for the jobs.
156 comments
[ 3.7 ms ] story [ 210 ms ] threadPractically infinite private repos, privacy, automate/customize all you want.
[0]: https://woodpecker-ci.org/
Here is an example pipeline I use to build and deploy Ditzes (my offline/desktop HN client):
https://codeberg.org/ditzes/ditzes/src/commit/410486175a2dea...
I’m considering switching my NW.js app over to Tauri, but I’m a bit hesitant due to the work involved.
There are still some bugs around that are a bit of a hassle to deal with, but only one that is a showstopper for me personally (the back button on the mouse doesn't navigate back), otherwise it works out well for me.
1: https://docs.gitea.io/en-us/oauth2-provider/
A small example, we create users for our customers in gitea and they are only part of the "customer" organization. This automatically get them access to the "customer" worklog as they access the customer area. So gitea is for us the central identity management.
[0]: https://github.com/go-gitea/gitea/blob/main/services/webhook...
Among all the possible things to get worked-up about this seems like nothing (unless you are purist that considers including optional functionality to interface with a proprietary-service to be harmful).
https://gitea.com/gitea/awesome-gitea
[1] - https://wiki.archlinux.org/title/cgit
https://git.zx2c4.com/cgit/about/
Personally I like even MORE basic than gogs or gitea and use this at my own company:
https://git.zx2c4.com/cgit/about/
It's like a single binary packaged up, and a few lines on openbsd httpd to get it running. Pretty sweet!
Now as it happens, I actively don’t want any of that stuff for something I’m hosting for myself for my own projects only. I pretty much just want the parts you’d get in gitweb or cgit, but done better (since neither of those is very good; I run gitweb because I wasn’t impressed with either, but gitweb was easier to patch into a more acceptable shape). Is Gitea capable of being pared down to just this? Is there anything else that fills this niche?
it was something short, the url too. it was sh or st something.
can anyone get which one I mean?
edit: YES! it's sr.ht. thanks, commenter below this :)
What issues did you have with gitweb? And what stuff did you patch up?
It’s not everything I’d like changed, but it’s everything I have changed.
[1] - https://fossil-scm.org/home/doc/trunk/www/index.wiki
Happy user of fossil since over 10 years now, both in individual projects and teams' projects.
For me, unlike git, fossil just gets out of the way and let's me focus on delivering. Doesn't have a whole bunch of arcane commands.
https://andreiclinciu.net/blog/why-im-using-fossil-scm-inste...
And from a quick bit of web searching, it looks like most IDE's out there either lack a plugin for fossil, or else have a plugin that's outdated and doesn't keep up with the current version of the IDE.
I realize that all of these "I Like X!" silly HN threads invite a lot of "I Like Y!" silly replies, but there sure are a lot of caveats on "better" here. You could make a much stronger case for recommending Subversion or CVS, lol.
https://nlnet.nl/project/Gitea/
https://forgeflux.org
https://forgefriends.org
https://forgefed.peers.community
And the default setting happens to be private.
https://docs.github.com/en/get-started/quickstart/create-a-r...
What I will often do if I want to instantly mirror something to github:
Which will create a new remote with that name. Otherwise origin will be used, which can conflict if you already have an origin remote.It is also less typing.
[1]: https://github.com/github/hub
Another company was famous for this, they used to call it Embrace, Extend, Extinguish
Does github provide the code of their servers that implements the API? Can you self-host it? If not, then it is pretty proprietary.
Of course, we/I understand open source software isn’t perfect and such. That isn’t my point, I’m just saying that Gitea could use a complete rewrite, ideally using NextJS (if SSR is that important) or moving most if not all view logic into the client side, ditching go-macaron and xorm for something more widely used, relying less heavily on go templates, and doing error handling a bit better.
That said, Gitea does have a good excuse which is that it inherited many of these things from Gogs, from which it was forked.
As for the so what, I think the answer is just that things can be better, so if someone is out there reading this thread who has some time, they can see this and know what kind of improvements can be made.
> If it ain't broke don't fix it? Or is there some specific shortcomming that might justify a rewrite?
I’m answering that question. The information is out there, so if people want to ignore it that’s beyond my mandate. But this is still constructive since someone out there wanting to rewrite Gitea will want to know what the pain points are before they do so.
(I really do want to know, I don't mean this question in any negative way.)
Then there are clerical things like where to put styles and presentation logic. Gitea uses a mix between jQuery and Vue, with CSS rules sprinkled in randomly. The result is that by looking at the template and the class names on each element, you have no idea whether a class name or ID is going to have significance to jQuery, CSS, or if it's just dead code. Something like styled-components, and use of a single stack (Next as opposed to jQuery+Vue) eliminates the fear and clerical aspect of development.
> nonstandard web framework (go-macaron)...
The "standard" is React and Vercel offerings. Get with the times.
> ditching go-macaron and xorm for something more widely used...
You're only supposed to use libraries that are #1 popularity in their respective category, few weeks of no commits means the library is dead.
> I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice...
Yes, you read that right. This is the advice for Gitea: Github, Gitlab, SourceHut all used server-side templates, so much so that latter two are quite useful even when JS is disabled- but the "better engineering choice" (citations sorely needed) is NextJS.
Xorm is so old and disused, it's been absorbed into Gitea and the Github repo is archived as read-only. You get much better capability out of something that's widely used, that's it. I don't care at all about how "modern" something is, if you can't roll back a migration because of your ORM then you have a nonideal ORM.
> The "standard" is React and Vercel offerings
No, I was thinking Gin or Buffalo. Something that a lot of people use and that's seeing a lot of love, you know... a standard.
> they can't simply accept when someone does things differently.
Yea, that's why I continue to accept Gitea as a good piece of software. Only people who cannot accept software packages as they are go out, call them "good", and try to get people to understand how it can become even better.
For migrations, if a migration fails, you have no way of rolling it back because they only go up and not down. This is just a specific instance of the problem of having less popular dependencies — the bug fixes and new features are less plentiful because there’s not as wide of a community. That applies to xorm and go-macaron.
Here's a good sample file. The cyclomatic complexity is through the roof: note the variable assignments, function calls, string concatenation, large number of `if`/`else if`s, nested conditional expressions (line 254). I don't even want to know how many permutations of this page are possible...
I have a wireguard with the server running on a small VPS, which is useful for both ignoring filtering on public wifi and getting into my home network from wherever.
If I do go this route do you have any suggestions with respect to security?
A bit less hands-on solution could be something like tailscale.
Also, things I want to look at on my home network mostly work fine over ssh (console stuff, git, etc). So I haven't actually gotten around to setting up full routing yet, and use the wireguard endpoint box as an ssh jumphost / bastion (and can forward ports if I do have something to get at that doesn't like to play nice).
https://community.torproject.org/onion-services/advanced/cli...
2008: Github launched
2008: Bitbucket launched
2010: Atlassian purchases bitbucket, makes private repos free
2011: Gitlab launched
2014: Gogs (Gitea's predecessor) first public release
2016: Gitea forks from Gogs
So at the very least, bitbucket was established and gitlab was around
[0] https://trac.edgewall.org/wiki/TracGit
I don’t even know why. Just seeing the interface rubs me entirely the wrong way.
Indeed fossil-scm [1], has same interface as Trac (in my view partly inspired by it). Have used Trac for a long time, so can't complain, it works well, its simple and flexible.
[1] https://fossil-scm.org
Bitbucket had free private repos for a long time. There were other services as well.
I experienced the "Try Gitea" service and migrated our TiDB repo https://github.com/pingcap/tidb to it. When I clicked the Activity tab and selected "1 year" period, I found the page loading was so slow, nearly 90s. And I also found that this Activity doesn't have a Cache, I re-selected "1 year" again, and the page loading was nearly the same time.
I guess Gitea uses git command to traverse all the logs for the period every time. Maybe it can use a database to speed up, or like Github only provide at max "1 month" period.
Trying to same on Codeberg, which is a production environment of Gitea, the loading time of the "Activity" page for Codeberg/gitea seems to take ~5 seconds for me. It still seems to lack any sort of caching, but at least it's relatively fast. See https://codeberg.org/Codeberg/gitea/activity/yearly (people might want to be careful hitting that URL over-and-over, in case we ddos the Codeberg folks :/ )
Yes it is an open source project, but the entire team that works on it is based out in China, and that's really not something you want to play games with.
For tools like this the aim is always to lay low and expand to reach as far as possible, then once you have a lot of control and trust you can abuse it, often you can abuse it without much loss, because once you have institutional momentum it's very hard to screw it up.
You can't operate on If there's a history of abuse of power, only if there is an incentive. I believe there's a very strong incentive in this case.
The fact that itself hosted is actually a really huge concern, because this thing is sitting on your local network with no firewall between it and everything else that you run.
It takes very little to put a vulnerability in a piece of code, and unless you have a person combing every commit with a fine tooth comb, even the fact that it's open source cannot prevent that.
No single security measure is bulletproof. Being open source does not counteract the misaligned incentives.
No offense to anyone and do not want to imply anything nefarious is about but from what I remember Gogs was even worse in that only a single maintainer inside P.R.C had merge access to the main branch. Also a concern because I might remember something about known vulnerabilities having been outstanding on the issue-tracker when the maintainer was busy.
Maybe you could expand on why this is an issue.
The fact that it's open source helps a little bit, but I do not believe they number of eyes on the project is enough that they couldn't sneak something through if they wanted to. This isn't Linux with worldwide attention, it's a relative niche.
It looks like they got developers from bunch of other locations at least according to their Github activity.
But you are correct, they do get commits from outside of the country
On Gogs it's not configurable and to stop publishing names of all users, including admin account username, it's necessary to either close down the whole service (disable public view of all repos and disable signup) or block certain addresses on proxy level.
[1] https://gitea.com/explore/users
edit: to clarify. It’s fine for a one man show or a small company. Once you get bigger, you start hitting the various issues quite often, and wish for github again.
I'd like to be able to get a list what i'm watching and filter it on repo, author, type (issue/pr), and reason like I very often do in github.
There is also no session managment accessible from user side :(
The only problem that I've found is that my github repo now shows very little activity which make job hunting harder.