Kallithea – Self-hosted alternative to GitHub | Hacker News Reader

Kallithea – Self-hosted alternative to GitHub

kallithea-scm.org

198 pointsdragonsh125 comments

For personal, single-person projects I went back to a bare (git init --bare) repository on my SMB share. I tried gogs and gitea, and at some point, I encountered a bug where the cpu would spike to 100% constant load, and make my instance impossible to use. I also didn't want to run Gitlab on my NAS for performance reason.

I'm pretty happy now, with one system less to manage (although I don't want to discourage anyone to have a look at Kallithea - maybe it suits your needs!)

> git init --bare

Aha, '--bare': what does that do? I always just type 'git init'.

Let me do a little git bashing, OK? Sorry for this, but it so nicely documents my initial problems with git when I started a few years back. And it still occasionally (like right now) makes me shake my head in disbelief:

> man git-init

Searching for --bare gives me:

> --bare

> Create a bare repository. ...and how GIT_DIR is set...

You don't say!!

I search for other occurrences of 'bare' in that man page, but after skipping those in the synopsis and the help text, it says:

> Pattern not found

So bare = bare. Tautological documentation. It's all obvious, right?

What --bare really does is to put what git would normally put into the '.git' subdir into '.'. I tried what it does, that's how I found out.

Git is great, but please never claim that it is intuitively documented.

The man pages are indeed not great. I usually invest a bit more time reading the git book, it explains what a bare repo is a bit better: “ a new bare repository — a repository that doesn’t contain a working directory.” From the “setting up git on a server” chapter (https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git...) which I think is the main reason why one would use a bare repo.

That said I concur and don’t think anyone would make such a claim about git documentation.

If all else fails, try https://git-man-page-generator.lokaltog.net/ :)

Here's the very short answer:

A bare repo has only Git's own data structure files. It's basically the contents of a non-bare repo's ".git/" directory, without a checked out working copy of all the files that are contained in the repo. The files are all still there but stored inside Git's database and not in the filesystem in the normal way.

The advantage: you can push commits to a bare repo. It's the kind of repo you'd put on your remote dev server. If you try to push to a non-bare repo, you'd get an error message like:

  remote: error: refusing to update checked out branch: refs/heads/dev
  remote: error: By default, updating the current branch in a non-bare repository
  remote: is denied, because it will make the index and work tree inconsistent
  remote: with what you pushed, and will require 'git reset --hard' to match
  remote: the work tree to HEAD.

...which is a long way of saying "don't do that". The disadvantage is that you can't cd into a bare repo and use "ls" and friends to browse around.

So here's the even shorter answer:

Make a bare repo when you only want to push to it but not work inside it, say because you're making a shared repo for you and your friends to work on together.

Make a non-bare repo when you want to work inside it but not push to it, say because it's a project you're developing on your laptop.

This is as short as I can make my understanding of what you are saying:

A bare git repo is a server side git repo while non-bare is client side.

Nailed it.

git user interface design is a disaster. It's no wonder it's hard to document (this is a bit orthogonal to your point...).

Git has an extremely complex data structure/state: It's a forest of DAGs (commits in distributed repos), with labels on them (branches), that have specified relationships (remotes), as well as an index and a stash per DAG. All of this on top of the working directory (and .gitignore if you want).

Of course these individual elements are mostly necessary to enable complex workflows. But simple workflows interact with all of these elements too in complex ways. This complexity is neither hidden behind a sensible set of UX abstractions, nor are they cleanly exposed to the user with a set of clean elementary operations to work on them...

Mercurial works more or less the same way, and yet I find mercurial UI much simpler.

The main difference, I think, is that mercurial has stronger opinions on how you should manage your repository and hides everything that doesn't fit its views behind extensions.

Really, I don't understand how git managed to become so popular. It is really good and I like it a lot but it really takes time getting used to. I screwed up a lot before getting competent with it, and I still screw up from time to time. It didn't happen with cvs, svn and mercurial.

It makes me think of Perl. Powerful and messy, I like if for the same reason I like git. But while Perl is on the way down, progressively replaced by cleaner, more opinionated alternatives, git is becoming a de-facto standard.

I’ve always believed that it was GitHub that allowed git to win out.

In addition to that, I suspect it was the very fact that Mercurial had more features, specifically an in built web server that allowed you to easily share your repo, led to GitHub being created with git and not mercurial.

The way I look at it, Mercurial made it extremely easy to self host a repo. So there was no need for a 3rd party centralized service to share your mercurial repo. That wasn’t the case for git, so something like GitHub was needed.

But the centralization in GitHub also allowed them to add more social features, which allowed git to spread more widely.

It’s almost like git was written by kernel programmers who knew only C and Perl.

[Shameless plug] If all you need is the ability to manage a bunch of personal repositories hosted on your ssh server, you may want to try "reposetup", a minimalist, shell-based, repository manager: https://github.com/agateau/reposetup

While that is true, I did try searching the main git man page for GIT_DIR and found it said the following:

> GIT_DIR

> If the GIT_DIR environment variable is set then it specifies a path to use instead of the default .git for the base of the repository. The --git-dir command-line option also sets this value.

That said, manuals are typically written like this, meaning that for terms one isn't already aware of, there is a need to search through the index to find its meaning and them piece together the information.

> git init --help > OPTIONS > --bare > Create a bare repository. If GIT_DIR environment is not set, it is set to the current working directory.

I'm confused on what you find confusing here?

> git init --help > OPTIONS > --tiramisu > Create a tiramisu repository. If GIT_DIR environment is not set, it is set to the current working directory.

Ok, so can you tell me what is a tiramisu repository?

Are you saying you don't know what the word "bare" means? Is that the confusion?

Googling for the definition I find "Bare: without addition; basic and simple."

And yes, I can. A tiramisu repository is a fictional repository that is not at all mentioned the very helpful help section of git init. While completely fabricated, the tiramisu repository is one of the best tasting repositories git can produce.

This is the exact point the parent post makes. You have to google what the hell is a bare git repository. It is not intuitive or clearly documented.

If the directory containing the git objects is not set, it is set to use the directory you normally find a working tree in. This is pretty straightforward once you know the basics of git, and I can’t imagine anyone would be creating a repo holding only the objects (a remote only repo you simply pull/push to/from) until they know the basics of git.

git is split up in many man pages. That's generally a good thing, but you sometimes have to search or look at more than one man page to find what you are looking for.

You could try

> man -K "bare repo"

to search all man pages for that string, and you'll find that

> man git-clone

has the information you are looking for:

"--bare: Make a bare Git repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git, make the <directory> itself the $GIT_DIR. This obviously implies the -n because there is nowhere to check out the working tree."

If you have Internet connectivity, Google is also an option. Among the first hits should be the book "Pro Git", chapter "4.2 Git on the Server", which begins with a concise explanation what a bare repository is.

> ... but you sometimes have to search or look at more than one man page to find what you are looking for.

Well, yes, that's one of the problems. I am saying the docs are unintuitive, and now you are confirming that.

For 'git init --bare', I look into 'git-init' and search for '--bare'. That's what I do, that's intuitive to me. And that's not where the info is. Is all I am saying.

Another good option if you need to start moving your repos to other machines or want to back them up is using rsync.net. They added git support many years ago and it's just like setting up a bare repo on a remote SSH host but all managed by rsync.net: https://blog.kozubik.com/john_kozubik/2010/02/git-and-subver... Once your repos are there then accessing them from anywhere is just a git-ssh clone away, just like a private github repo.

If you just want to use for personal single-person projects fossil [1] and mercurial [2] may be a better choice, given both come with in-built web interface. Just run hg serve or fossil server or fossil ui. No need any external platform or program.

[1] https://fossil-scm.org/home/doc/trunk/www/index.wiki

[2] https://www.mercurial-scm.org/

I personally use Pagure[1] for mine. I use it because Pagure is fairly easy to install and maintain and it's packaged in virtually all major distributions[2][3][4][5]. I can easily develop my personal projects in them, have my own kanban boards for task tracking, and all the project data is stored as Git repos, which makes it easy to archive and replicate (with full project history).

I've got a personal instance running on openSUSE in a tiny 1 vCPU+1GB RAM VPS, and it works really well. It's fairly lightweight on resources, too (my VPS instance rarely sees significant load).

[1]: https://pagure.io/pagure

[2]: https://src.fedoraproject.org/rpms/pagure

[3]: https://build.opensuse.org/package/show/openSUSE:Factory/pag...

[4]: https://packages.debian.org/sid/pagure

[5]: https://packages.ubuntu.com/focal/pagure

(Offtopic) You can simplify [2]–[5] to just ¹.

¹https://repology.org/project/pagure/versions

Hmm, yeah, I guess I could. I'll keep it in mind for the future. :)

This looks great!

I've been using fossil for personal projects, for the last 3 months. The all-in-one aspect is great, and it's literally 2 commands to start a server. When I need a new remote repository, I just have to copy the .fossil file on my VPS. The only thing I don't like is the issues management, which isn't user-friendly at all.

I didn't know that mercurial had a web interface, I'll certainly take a look this week.

Git also has git-web and gitk for local GUI usage.

Not to forget git gui, that allow you to pick lines to commit instead of the whole file

So does

    git add --patch [FILE...]

btw (by invoking your $EDITOR).

Is there a good git -> fossil tutorial/migration guide?

Fossil itself has a decent translation guide:

https://fossil-scm.org/home/doc/trunk/www/gitusers.md

I have used bare repos managed by gitolite for close to a decade. Works great, and I never touch the config because I set up wildcard repos long ago.

I just set this up and I'm quite happy with it. I did not know about wildcard repos, I'll check that out.

Gitea is riddled with bugs and the maintainers seem to disagree they exist, which is a shame.

We too just switched to bare repos and haven't really missed much from the SCM frontends.

Gitea maintainer here :) Is there an issue/PR you can point me to? I'd be happy to take a look and see if we can get it on the roadmap. We're working on improving testing strategy to reduce new bugs. We don't include front-end in our tests right now, which is imo our biggest issue. Would love some help with the this. We just support so many platforms, databases, and config options it's difficult to catch everything. It's a great project to work on and there is plenty of room for improvement!

Thanks for your work on this nice piece of software! We created our small company last year and it has not only been our VCS (nicely integrated with Drone for CI/CD) but we also based our SSO on it (we had to add a homemade OIDC/OAUTH proxy though). I'll hopefully soon find the time to clean-up the code of said proxy and of the helm chart we wrote in order to propose a contribution to this nice project. I deployed and run Gitlab for a large company and have used it in other contexts in the past. While Gitlab's feature set is obviously much wider, Gitea is a nice trade-off when a lighter footprint is desired. Thanks again!

Hi. You all but shut down my criticism of the mirroring system and the fact that it fails outright if Gitea dies in the interim - sometimes even due to Gitea deadlocking itself - and insisted this was SQLite's problem and not Gitea's.

That's the one example I'm referring to.

Since then, we faced a number of UI bugs that we just didn't bother to report since most other attempts at reaching out were rejected as "not our problem".

We have quite the queue of projects, but we're actually working on the mirroring system and front-end tests. See:

- https://github.com/go-gitea/gitea/pull/15268

- https://github.com/go-gitea/gitea/pull/14726

- https://github.com/go-gitea/gitea/pull/15315

- https://github.com/go-gitea/gitea/issues/14639

We're a volunteer team, so any information you can add to an issue would be greatly appreciated. Even if you're not using Gitea anymore.

Luckily for me Gitea has been working without any problems for some time now. And I would rather fix those issues than switch to bare repos.

> and the maintainers seem to disagree they exist, which is a shame

Does this extend also to the case of when someone submits a pull request to them, or only for issues that people file?

If the former then it is truly problematic. If the latter they may be simply overworked/overburdened by the volume of issues that are being filed, and could need more people submitting pull requests instead of opening issues.

> If the latter they may be simply overworked/overburdened by the volume of issues that are being filed, and could need more people submitting pull requests instead of opening issues.

Although merging and reviewing a pull request can also be quite time-consuming. If you are already overworked, it might add to the problem. I'm happy that none of my open-source projects went through the roof. I won't be able to manage it alone.

They aren't saying "we can't fix this right now". They're saying, straight up, "this isn't a problem".

Pictures or it didn't happen. One of the maintainers has responded specifically to you here and you have ignored their outreach.

> One of the maintainers has responded specifically to you here and you have ignored their outreach.

The maintainer has responded more recently than the GP's last comment. "ignore" feels like a stretch.

Lol, "ignored". Why are you so angry? I don't check HN every waking minute of every day. In fact, I have noprocrast enabled, so I can't.

Please stop assuming malice in others. You'll be a happier person.

I've responded to the dev, FWIW.

I enabled SSH on my NAS and use git over ssh for some stuff that never leaves my home network. For stuff I share a bit more widely I use git-shell over SSH with a few scripts to create and list repositories on a 5$ VPS.

But for bigger projects I now use github as I missed CI and pull request review flows, even for my own work

> I encountered a bug where the cpu would spike to 100% constant load

A bit off topic - but is that an underlying problem with go-lang projects? I've seen a similar problem when using a couple of other go-lang tools, where the entire CPU hits 100% and locks the machine. Too many channels/threads perhaps?

Simple chan deadlocks, lifelocks or loops will do that for you.

Thanks. I don't have much experience in go, but that makes a lot of sense.

How does this replace a Git web interface, though? I guess you could have it serve simple index.html pages but I don't see how you're going to get code browsing and issues and PRs, except maybe locally on your machine.

> How does this replace a Git web interface, though?

It doesn't. And it shouldn't.

I don't need code browsing on my SMB repo because, well, I'm the only one working on it. And even if I weren't, it'd be kinda fine anyways. I don't have the extra layer of security, but I don't need that either: I already need credentials to connect to my SMB share.

PRs - well, single project. It's just for me, so merging my own feature branches seems fine.

Issues are indeed an "issue". I simply track them in a markdown file. Whatever floats your boat should be fine, though. Combined, for me personally, it works better than managing a platform I don't really need.

For issues, there's git-bug: https://github.com/MichaelMure/git-bug

That's nice, thanks!

It makes sense that most distributed version control system features wouldn't apply to a single user.

I've gotten pull requests for some of my personal single-person projects. It's very appreciated, and I doubt they would come as much if the only interface was a read-only git repo and an email address.

I've got some open-source projects as well that are hosted on GitHub, where I accept (and appreciate!) pull requests. But there are some projects I work on in my spare time, just for the fun of it. I don't need feedback on these. At least, not yet. For this, it's just nice to have something "locally", yet automatically backed up on my SMB share.

Same! I tried gitea for a while but I found out what I really needed was a git remote I could access over ssh. It is way easier to manage

why not use github private projects? It's free.

without liability but with TOS. LOL, srsly?

What's that good for?

Because https://news.ycombinator.com/item?id=26709159

..which is unfortunate.

You could put gitea in a container and limit it's resources, what benefits does a bare metal install give you?

Ignore this, not sure what your issue with those apps are

These URLs kill me, I share a lot of links and these branches use full commit strings (instead of just "default" or "stable" human readable) and the links it creates to PRs includes the actual title (which I find I can delete manually, but this is the default behaviour).

stable: https://kallithea-scm.org/repos/kallithea/files/7f3515800bd8...

PR: https://kallithea-scm.org/repos/kallithea/pull-request -> https://kallithea-scm.org/repos/kallithea/pull-request/140/_...

(...which you can delete everything after /140/ and it works fine). Oy vey.

>(...which you can delete everything after /140/ and it works fine).

This is good pattern but not implemented correctly. It should rewrite to full correct url. It can be abuse like this:

/140/_/ThisProjectSucksDontUseIt-UseThisOneXXXXXX

https://kallithea-scm.org/repos/kallithea/pull-request/140/_...

That doesn't seem like a new problem to me - you can already give someone a link with extraneous info in it using query params and fragments:

https://google.com?you_should_use_bing_instead

https://google.com#you_should_use_bing_instead

cazim's point was that the url path should still work but rewrite back to the correct canonical URL.

Query strings and hashes are a little different, since those may contain information you might not want to scrub.

"Vanity" paths in particular can be rewritten because you often have a "correct" value for a given route.

e.g. https://community.nodebb.org/topic/180/who-is-using-nodebb

You can rewrite the tail end of this URL to whatever you'd like but it will always redirect you back to the correct canonical slug.

There's also Heptapod (https://heptapod.net), a GitLab fork that is built around native support for Mercurial. I have been using it on a private server for a while now. It's been solid and reliable so far and I like it.

Github is not a programming tool. Github is a social network. It's value is that it has network effect dominance. That's why microsoft bought it. That's why people use it. I don't see many uses for this if it doesn't allow for stuff like federating to re-achieve the social network aspect outside of network effect centralization.

I suppose if you're a small group of people that don't need github's main feature (other people) and just want a local github-alike for playing it's cool. But why not just git then?

On the contrary I think "source control with a nice web UI and no social network" is a category of product that a definite part of the market wants. Look at projects that choose to be "open source, but not open contribution" like SQLite--they don't want a free-for-all drive-by pull request community. They want a way to publish code for all to see and consume, yet be maintained entirely by a single or core set of contributors.

Github's popularity is proof enough in itself that the vast majority want the social network of Github.

That's certainly one use case, but most definitely not the only one. There are tons of corporate customers who use Github and don't give 2 shits about the larger social network aspect of it (I mean, for one, just think of all the users that use on-prem Github).

> Github is a social network

Is it? I would have said it was a collaborative tool. I don't use it to 'socialise' and 'chat' with other users. I use it to thrash out PRs.

But I do agree with the gist of what you're saying.

Very much a social network. Look at your profile/activity feed and how it gamifies contributions with the activity chart (the more you do across github, the more it lights up). Github project stars are just the same as FB likes. Or how they prominently put fork buttons on every repo that immediately clone and copy a fork of the project to your repo. Or that github has an entirely new inbox of messages and issue replies to deal with (and all the issues of potential harassment, etc. that come with that honestly).

> GitHub is a social network

Yes indeed social network like Facebook, which can stop access to repository or code based on DMCA. It pose many serious risks, given a lot of open source code is under control of a single corporate entity.

Hopefully social model evolves and become fully distributed which is the fundamental basis of git/hg/fossil and other distributed version control.

Today all the necessary technology is available, needs an effort to integrate them and bring back the self-hosted alternative which automatically forms a distributed social network to collaborate on code.

GitHub is a social network - with far better UI/Ux than all the other social networks other open source software tries to use. It is also the location from which many packages do their releases and a very helpful tool when managing large scale projects (usually). GitHub also provides a self-hosted version, but imo they are slow with feature delivery in some cases and an open source project that really dug in would be great.

I know about gitlab et al, but nothing really quite creeps up to the same level of GitHub

We use something similar to this for a team of 5. We can coordinate about 30 repos, manage issues, have deployment from source mechanisms and so on. It's definitely got a use.

Personally I would be much too cool to actually socialize on GitHub.

I must admit there is a use case for something like that, though I also must admit that I personally feel the same

How does any of those similar solutions solve the data backup problem? I always think GitHub / GitLab also serves as an off-site backup.

I use Gitea to self-host. Since I do not have rest of the world to serve, just my company, I use script that at 3 AM stops servicing all requests, shuts down Gitea server and does binary backup locally and then also sends backup to offsite servers. After backup it restarts the server. Since Gitea is configured to use SQLite backing up database part is just the part of that binary files backup.

Separate script can restore from backup. All in all seems pretty safe to me. Obviously it does not scale to Github proportions.

It's not just the scripts. There is an offsite server need to be setup, and maybe paid to keep it reliably running for the long term.

Sounds too much ado for nothing compared to use free private repos on GitHub / GitLab.

I do not have standby servers just for git. I run small software development company hence we have it anyways already. We have products that run on servers. Servers are self hosted with standby servers rented elsewhere. I have this infrastructure already for many years. Standby servers do not cost a lot in monthly fees and for what we do it is orders of magnitude less than cloudy companies would charge us.

Maintenance wise it is easy. In any way I am not letting other company to be in control of my infrastructure and data.

I don't think Github or Gitlab have serious SLAs unless you're an enterprise customer. Don't stake the future of your project or code on the backup and management of a service you pay no money to use. Keep at least your own local clones and offsite backups. The 3-2-1 rule still applies if it's data you care about.

A. GitHub / GitLab + local clones

B. self-hosted server + self-maintained offsite backup

A is obviously easier than B. And also A has tons of other benefits.

I am in the process of dismissing my private personal gitlab instance, and It's unlikely that I'll install something else. I plan using private repositories on the public gitlab.com.

The thing is, the killer feature for me is gitlab-ci (and private repositories). Using gitlab-ci along with my own runners (tied to a private group) along with git-crypt I should be able to do most things that I do in my small gitlab instance.

The thing is, alternatives are maybe lighter, but they don't pack as many features as gitlab and lack some kind of integrated-everywhere CI.

Leaving git, I'm not even considering that.

Have you considered gitea + drone?

Is Drone useful if you need to build anywhere other than Linux? Yeah Docker can run elsewhere, but it's still Linux.

I'd love an excuse to leave Jenkins for self-hosted multi-platform jobs, but nothing else seems to have the flexibility and to project confidence that it'll still be around and well-maintained in, say, five years.

It looks that they have this functionality in Beta, but I haven't really tried that. All my jobs are in containers.

https://docs.drone.io/runner/exec/overview/

Nah, Gitlab is the definitve solution.

I really don't feel the need for anything besides gitlab + gitlab-ci.

We use mercurial in our startup and if need to use git, we keep a mirror of git repository in our kallithea instance. We integrate git in our internal workflow using hg-git.

Not sure of others but in the early years we chose mercurial over git due to to its beautiful command line UI, conceptual integrity and easier mental model. Even today hg is easier to pick up for new developers in our startup compared to git, even though git has bigger mindshare due to GitHub.

In hg specially like the default setting for immutable commit history and explicit merges unless forcibly overridden.

Our company transitioned away from hg a year or two ago and moved to an internal Gitlab instance.

hg had a way better developer interface and I miss it for that but all the tooling and integrations supported git.

One big benefit of Kallithea is that it supports Mercurial repositories.

Is this important? I know this might sound like an odd question, but I came into the VCS world with Git and have never used Mercurial, SVN, etc.

With Git permeating every enterprise and organisation I've contracted for in the past years, I'm surprised to see Mercurial support hailed as a win.

Also like the default in mercurial repository for immutable commit history and explicit merges unless forcibly overridden.

So still today use mercurial in our startup and if need to use git, we keep a mirror of git repository in our kallithea instance. We integrate git in our internal workflow using hg-git.

> even though git has bigger mindshare due to GitHub.

This is, as far as I can tell from my memory, ahistorical. While git was still young in 2008, it was already quite dominant.

The Linux's choice was hugely influential, and Linus' "angry and confident" style of advocacy has always been (regretfully) effective when used against software people. Git stole the mind share _very_ quickly, and by the time Github became a thing I remember almost everyone _wanting_ to be on Git. Hg and Bazaar were clear contrarians, even if I personally might have liked Hg.

I'm fairly sure that Github is "Git"hub due to Git's popularity, not the other way around.

Github is github because the team behind it had drunk the koolaid. They are responsible for passive-agressive marketing crap like this: https://svnhub.com This shows that they never had any intention to promote any other version control system.

Linus' marketing is a footnote compared to git's main feature for commercial software vendors: it's abysmal design flaws and utterly obtuse UI. That makes it incredibly easy to earn money by tacking on stuff that makes that abomination actually usable. I'd wager that github's success is built on that.

I prefer Gitlab's "merge request" to Github's "pull request", too bad Kalithea chose "pull request" (super minor thing that does not really matter though).

yeah, "pull request" is terrible terminology. It confused me for years.

What's the difference?

The point being made is that 'merge request' is a better description than 'pull request' for the same functionality, where one requests that a repo pull from your fork's branch and merge it's commits.

> one requests that a repo pull from your fork's branch

So why isn't "pull request" a good name for a request to pull from a different repo?

The mechanism is a pull, followed by a merge. But what's interesting about the transaction is that your tree is merged with the upstream tree; the pull is just an implementation detail. You would be just as happy if the merge happened somehow that didn't involve a pull, but you wouldn't be very happy if there were a pull but no merge.

Nice looking and streamlined UI

However, the diff view appears wrapped on a mobile screen [1]. I'd prefer a scrolled diff, that is viewport fitting the screen, but the contents not wrapped. This would allow one to see long lines of code as is, instead of stacked in pieces.

Another wish is side-by-side diff view.

[1]: https://kallithea-scm.org/repos/kallithea/changeset/e6034764...

I use Phabricator as a self-hosted Git. It's slightly overkill for what I need - it's more geared for team working, but It's really simple to install and maintain.

How does it compare to existing solutions like Gitea or gerrit?

Just to clear up any confusion based on how you asked this question - Kalithea _is_ "an existing solution." It is not something new, but has been around since at least 2014. This is about the same time Gitea's predecessor, Gogs, was created. It's also around the same time Gitlab was launched.

I am less sure about when Gerrit was created, but it is possibly older.

I use one called Gitea which is not only a functionality clone of GitHub, but is also a UI clone too. It's free software and works great, and is written in go.

Gitea is a fork of Gogs which was a UI clone of Github. With a few years of UI changes neither is as close to looking like Github anymore.

Gitea isn't as full-featured as Gitlab, but it's so much easier to manage.

Great; I was looking at alternatives to bitbucket as we self-host and the self-hosted option is going away for Atlassian stuff (or so I've been informed by the procurement droid at our place).

Can anyone recommend a self-hosted alternative to Jira?

Maybe Taiga? https://www.taiga.io/

I've been trying out Taiga for the last few weeks and it's beautiful!

I'm not sure why it is such a well kept secret.

If you are okay with closed yource, there is YouTrack Standalone for up to 10 users. And of course there is Redmine, but I find it somewhat barebones. And GitLab also has some issue management chops.

Okay with anything, really. We're paying money for this no matter if it's open or closed.

Thanks, will check it out :-)

also there is open source https://www.taiga.io

A bit of tangent, but I'm building an app on top of git, a thin business logic on top of very specific type of repositories.

I'd like to reuse an existing api, for example Kallithea or Gitlab layer/api that interacts with git, does anyone have opinions which one would be easier to reuse?

I fail to find documentation from Gitlab on how services are organised, if they have a git api as a separate process and how to run just that.

Now I'm discovering Kallithea, I'll have a look to it, but really appreciate if someone has done this before and has some pointers where to start.

This page details GitLab's architecture: https://docs.gitlab.com/ee/development/architecture.html

On that page you'll find a link to docs for Gitaly, a Git RPC service that handles all Git calls made by GitLab.

thanks a lot!

Gitea isn't too bad to hack on, it's just Go and Go templates for the HTML pages. I haven't dug in much to see what their API looks like but I assume it's not too wild or radically different from any other Go web project and easy to change as necessary: https://github.com/go-gitea/gitea

The logo looks like the USB logo.

So instead of contributing time and resources to awesome open source alternatives that already exist, we have yet another competing offering. Awesome.

Open source development is only a full time paid job for a small number of people, for everyone else it is largely driven by passion. In principal, I'm not sure anyone should tell anyone else what they are allowed to do with their free time.

But if you had taken time to read the first sentence on the link, you would see that there is in fact a key difference:

> Kallithea [...] is [...] source code management system that supports two leading version control systems, Mercurial and Git

This is something that alternatives do not do [1] [2] [3] [4]. There are likely further differences if you read the documentation at https://kallithea.readthedocs.io/en/latest/readme.html

[1] https://github.com/go-gitea/gitea/issues/458 [2] https://github.com/gogs/gogs/issues/125 [3] https://gitlab.com/gitlab-com/blog-posts/-/issues/261 [4] https://www.gerritcodereview.com/roadmap.html

This project has existed for mor than 6 years. It is a fork of RhodeCode, which has existed for more than a decade.

When rhodecode went closed source, Kallithea was forked, and has been maintained ever since.

These days RhodeCode has a Community edition which is licensed under AGPLv3.

> contributing time and resources to awesome open source

do you or do you just give grumpy advice how others should spend their own time?

You’re not wrong per se but this community is a place to showcase interesting technology and this is one of them.

Maybe the author just wanted to build something to practice code or to do something different than GitHub.

Innovation (and evolution) happen via mutation - it’s wrong to ask people to conform to set standards in a forum dedicated to interesting bits of knowledge.

Reply on news.ycombinator.com