
Gitea – Alternative to GitLab and GitHub - philonoist
https://gitea.io
======
fuzzy2
Notable previous discussions:

\-
[https://news.ycombinator.com/item?id=17006503](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)

\-
[https://news.ycombinator.com/item?id=13451783](https://news.ycombinator.com/item?id=13451783)

\-
[https://news.ycombinator.com/item?id=13296717](https://news.ycombinator.com/item?id=13296717)

------
sago
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 pull requests (i.e. suggested patches). These are not
unique tools, there are many options for issue tracking and email.

I make this point because these solutions are trying to replicate smaller or
larger chunks of github rather than provide alternative ways to use git.

That said, Gita/Gogs is pretty. And might hold the hand of people only used to
github. It is great that it is self-contained as a binary, so can be used with
minimal configuration, like other front-ends.

But I worry that the emphasis on tools like this suggest we have accepted that
github-flavoured centralised version control ('gitversion', maybe, or 'gcs'),
rather than git, is now the de facto standard for version control. Am I
paranoid? Does it even matter?

~~~
tjoff
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 workstation wasn't on, can't update my laptop...).

Pulling code from random developers machines might sound pretty neat in
isolation but that is the exception and an edge case to something else. And
that something else should most likely be a centralized repository.

When people say they love decentralized version control I often get the
impression that what they really love is local commits. There is nothing that
says that you can't have local commits in a centralized version control
system, it is just that being decentralized is a neat solution for many
problems. But that is just an implementation detail that very few could care
about, had it not been hyped to death.

Now this is something entirely different than the whole developer community
putting everything in one basket (github), that's the only type of
centralization worth worrying about.

~~~
k__
AFAIK the Linux Kernel doesn't have a single source of truth.

~~~
ahauxuueei
You are mistaken.

Linux kernel dev branch single source of truth is
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/)

The stable branches have their single source of truth repositories, too.

~~~
falsedan
I think replying to "it doesn't have a single source of truth" with "actually
there are multiple single sources of truth" kind of makes the OP's case for
them.

~~~
angelsl
What are you saying??

There is a single source of truth for a particular version of Linux.

~~~
falsedan
I'm saying, you're wrong, and trying to wriggle out of being wrong by
redefining the statement.

------
PaulRobinson
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.

~~~
Freak_NL
You could open a well-worded issue for it (“Gitea code base should be hosted
on gitea instance”) and track that. There is a chance that the developers will
close it as a WONTFIX of course.

~~~
falsedan
> _well-worded issue_

Your example is not well-worded; it's a demand. I'd expect a well-worded issue
to share some story about how you were working to achieve some goal, so you
tried setting up gitea to self-host the gitea repo, and were surprised that it
didn't work (and share the errors etc. that you saw). Then the devss can
prioritise your issue by understanding how blocked you are by the missing
behaviour, and even propose a workaround or alternative way of achieving your
goal.

~~~
Freak_NL
The phrase between parentheses was meant as an example of the succinct _title_
of such an issue, not the hopefully polite and well-worded body explaining
why.

~~~
falsedan
> _the succinct title of such an issue_

'Title: do this thing' is not polite or well-worded.

"Let's self-host gitea so potential users can easily see how awesome it is" is
more polite, far easier to see the benefit of, and a trash-fire of proper
composition.

------
ofrzeta
Gogs, the project Gitea has been forked off, works just as well. As far as I
can see there's no technical reason to prefer the fork over the original.

Judging from Github stars, Gogs is also vastly more popular.

~~~
oxymoron
I compared them yesterday. There seems to be more development activity and
more contributors for Gitea (check the pulse tool on github for the last
month). I haven’t got a stake in this whatsoever, but I recall the rationale
for the fork being that PR’s would remain unmerged for months without comment
due to the inactivity of the original author, who nevertheless wanted to
retain control?

~~~
kerneldeveloper
Gogs has many issues that no one want to fix.

------
ainiriand
It is an awesome product, I really want to try it a bit more at home later in
the evening. Don't you think it could be a good idea that considering it is to
self host git projects, to self host your own project? I mean, why don't you
use your own product?

~~~
zaarn
It's probably a cost question, to my knowledge gitea.io is a github pages
website. The only running cost is really the domain.

Running the git service is probably a bit expensive and you loose the network
effect of github.

They could probably migrate to gitlab though.

~~~
spacebearmakes
gitea.io is run on Digital ocean. You can see the expenses here:
[https://opencollective.com/gitea](https://opencollective.com/gitea)

------
partycoder
This is the announcement of Gitea, which is a fork of Gogs.

[https://blog.gitea.io/2016/12/welcome-to-
gitea/](https://blog.gitea.io/2016/12/welcome-to-gitea/)

"We’re a growing group of former Gogs users and contributors who found the
single-maintainer management model of Gogs frustrating and thus decided to
make an effort to build a more open and faster development model."

This is a guide to run it with Docker [https://docs.gitea.io/en-us/install-
with-docker/](https://docs.gitea.io/en-us/install-with-docker/)

------
viach
Why it's considered to be an alternative? Github is all about social
networking for developers, not code hosting, or am I wrong?

~~~
criddell
I'd be interested to see some numbers about projects that actually leave
Github. Other than FUD about the Microsoft acquisition, has something changed
on Github that is making people talk about leaving? Why run away before
there's a concrete reason?

~~~
viach
I don't have numbers, but my opinion is that the serious big/popular projects
with some user base (contributors) will not bother, at least yet.

------
sshagent
What i like about the landing page is all the info is there. I don't have to
scroll down through whole screens at a time for each titbit of info

~~~
g105b
I was about to comment the exact same thing. Excellent seeing this kind of
marketing page in a world full of noise.

------
biztos
I wonder whether the user-friendly features of sites/services like GitHub
might eventually be displaced by feature-rich git clients like Tower[0].

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.

[0]: [https://www.git-tower.com/](https://www.git-tower.com/)

[1]:
[https://en.wikipedia.org/wiki/Cambrian_explosion](https://en.wikipedia.org/wiki/Cambrian_explosion)

------
huntie
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?

~~~
falsedan
The index is just a cache of the metadata of files in the working directory;
changing how the objects in the repo are stored won't speed up a 'git status'.

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.

~~~
huntie
I was thinking about this from the perspective of a server like Gitea. What I
meant by 'read the repo' is retrieve objects like commits to display them to
the user.

So on the server you should only ever have packfiles, and in order to
efficiently read packfiles you read the index (idx) file. I'm not positive,
but I think that this file needs to be read in its entirety in order to access
an object. Even if you don't _have_ to read the whole file, it's probably best
because you generally read more than one object at a time (e.g. if you display
a list of files in HEAD you read the commit pointed to by HEAD, read its tree,
and read all of the blobs in its tree).

My thought with using loose files rather than packfiles is that you wouldn't
suffer the memory overhead of lookup, you just open the file at
`objects/some/object` and parse it.

The real solution here is probably to get a server with more RAM and cache
repositories. I'd be interested to hear what GitHub does.

~~~
falsedan
GitHUb use DGit to (effectively) get loose objects on demand and cache them
locally.

Parsing the packfile indexes is ridiculously fast; even in a memory-
constrained environment the OS will manage loading data from disk so you only
use a few pages. Inflating objects from packs is slower & will trash your
memory; rendering to HTML will be even worse.

Perhaps 1GB is not enough RAM to host a webviewer of the firefox repo? Maybe
if you generate a static site version of it…

~~~
huntie
>DGit I was looking for this yesterday, glad to see I wasn't misremembering.

You're right, 1GB is not enough but it's all that I have so I have to make do.

------
jmstfv
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?

~~~
huntie
I don't know about Gitea specifically, but notabug.org uses Gogs which Gitea
is a fork of.

------
reacharavindh
I have always seen GitHub as the social Git. Of course I use Gitea for
personal & private projects, but if you want visibility and gain from network
effect, GitHub is where you needed to be.

With this MS acquisition, that proposition is starting to become a problem and
an uncool dependancy on MS.

~~~
spacebearmakes
Gitea is working on federation, so lock-in wouldn't be a problem

------
patkai
Just wondering if it's time to start to decouple the client and the server. I
did that with mail and use a native client only, and hosting a git repo on DO
or similar should not be too big of an issue either.

~~~
falsedan
For a solo dev, running a remote is a great idea and way cheaper than paying
for GH private repos. You're giving up some availability and disaster
recovery, but as a solo dev those aren't big problems (spin up a new host,
configure your SSH keys, push). I did this years ago!

When the remote is shared (with other devs or tools), then you have the hassle
of provisioning accounts, updating keys when they get lost, implementing ACLs,
setting them, recording who changes what refs for audit trails,
availability/backups becomes an actual problem, managing disk space + garbage
collection, etc. The time you spend on those interruptsion is time (and
concentration) that you're not spending on what you want to do. That's where
the value proposition of GitHub comes in…

GitHub then has the value-adds/lock-in of easy webhook integrations, gh-pages
branch, issues, wiki, and the web UI.

If all you want is somewhere to push code that's always available & private to
you, then I'd look into using some could-based object store to host your repo.
If you want to share the repo with other devs/tools… let me know where to find
99 other people willing to spend $5/month on this kind of thing.

~~~
spacebearmakes
Gitea is working on federation so there wouldn't be lock-in.

------
ChankeyPathak
HN discussion on available alternatives to GitHub.
[https://news.ycombinator.com/item?id=17241487](https://news.ycombinator.com/item?id=17241487)

------
francis-io
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.

~~~
merb
well I think besides gitea dump there isn't really another way of backup.

~~~
olavgg
I use ZFS snapshots with send & receive, works very well!

------
stockkid
I'd be more convinced to give it a try if Gitea's repository itself was hosted
on Gitea rather than on GitHub.

~~~
spacebearmakes
The project is working on that, see this issue for status:
[https://github.com/go-gitea/gitea/issues/1029](https://github.com/go-
gitea/gitea/issues/1029)

------
virgilp
> Open Source: It’s all on GitHub!

There's some level of irony in a GitHub alternative that's hosted on GitHub.

~~~
spacebearmakes
It is currently something that is being worked on. See this issue for status:
[https://github.com/go-gitea/gitea/issues/1029](https://github.com/go-
gitea/gitea/issues/1029)

Self-hosting also takes resources such as time and money, and not all open
source projects have the latter.

------
Narann
> Gitea is a community managed fork of Gogs

Why fork the project instead of keeping a single one ?

~~~
nsomaru
There was an issue with the Gogs maintainer going AWOL for long periods of
time. An earlier fork was merged back in when he returned, but a subsequent
incident resulted in a permanent fork.

Also there were some governance issues IIRC.

------
marcelc63
I stop at self-hosting

------
tscolari
lol microsoft just announced it's going to buy GH and GH is already down :p

------
SuperNinKenDo
Looks great, but the fact they won't dogfood means I'm gonna stay away for
now. Definitely have my eye on this as an option though.

