11 ms·

Kallithea – Self-hosted alternative to GitHub

198 points by dragonsh 6y ago

10000truths 6y ago
How does it compare to existing solutions like Gitea or gerrit?
- cooperadymas 6y ago
  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.
gmueckl 6y ago
There's also Heptapod (https://heptapod.net 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.
quietbritishjim 6y ago
One big benefit of Kallithea is that it supports Mercurial repositories.
- movedx 6y ago
  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.
  - dragonsh 6y ago
    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. 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.
    - LaGrange 6y ago
      > 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.
      - gmueckl 6y ago
        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 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.
MrGilbert 6y ago
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!)
- junon 6y ago
  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.
  - codetrotter 6y ago
    > 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.
    - MrGilbert 6y ago
      > 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.
    - junon 6y ago
      They aren't saying "we can't fix this right now". They're saying, straight up, "this isn't a problem".
T3RMINATED 6y ago
gitlab is better
docsaintly 6y ago
So instead of contributing time and resources to awesome open source alternatives that already exist, we have yet another competing offering. Awesome.
- muxator 6y ago
  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.
  - bjkchoy 6y ago
    These days RhodeCode has a Community edition which is licensed under AGPLv3.
- tweetle_beetle 6y ago
  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 https://kallithea.readthedocs.io/en/latest/readme.html [1] https://github.com/go-gitea/gitea/issues/458 https://github.com/go-gitea/gitea/issues/458 [2] https://github.com/gogs/gogs/issues/125 https://github.com/gogs/gogs/issues/125 [3] https://gitlab.com/gitlab-com/blog-posts/-/issues/261 https://gitlab.com/gitlab-com/blog-posts/-/issues/261 [4] https://www.gerritcodereview.com/roadmap.html https://www.gerritcodereview.com/roadmap.html
- mro_name 6y ago
  > contributing time and resources to awesome open source do you or do you just give grumpy advice how others should spend their own time?
dragonsh 6y ago
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.
- tempest_ 6y ago
  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.
apples_oranges 6y ago
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).
- k__ 6y ago
  What's the difference?
  - webmaven 6y ago
    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.
    - ptx 6y ago
      > 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?
      - moonchild 6y ago
        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.
- steviedotboston 6y ago
  yeah, "pull request" is terrible terminology. It confused me for years.
sneak 6y ago
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.
- timw4mail 6y ago
  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.
temp8964 6y ago
How does any of those similar solutions solve the data backup problem? I always think GitHub / GitLab also serves as an off-site backup.
- FpUser 6y ago
  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.
  - temp8964 6y ago
    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.
    - FpUser 6y ago
      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.
- qbasic_forever 6y ago
  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.
lelanthran 6y ago
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?
- poisonborz 6y ago
  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.
  - lelanthran 6y ago
    Okay with anything, really. We're paying money for this no matter if it's open or closed. Thanks, will check it out :-)
  - mxuribe 6y ago
    Oh wow, i remember YouTrack! I have not used it for about 5 years or more now. I used it as a client to a dev agency, and really enjoyed the experience. My understanding is that the client/guest view - at least back then - wasn't even the full cool experience...so from client side, YouTrack was absolutely great! I have never used it as a dev., so no idea what the difference is, or how things work for a dev., or if better/worse, or what. I even remember that for another agency that we had to work with, they choose Jira...and my peers and i all hated Jira...but we all loved YouTrack...again, back then - no idea if things have changed. Thanks for bringing back that positive memory of YouTrack!
- elviejo 6y ago
  also there is open source https://www.taiga.io https://www.taiga.io
- nerdponx 6y ago
  Maybe Taiga? https://www.taiga.io/ https://www.taiga.io/
znpy 6y ago
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.
- kavalg 6y ago
  Have you considered gitea + drone?
  - gh-throw 6y ago
    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.
    - kavalg 6y ago
      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/ https://docs.drone.io/runner/exec/overview/
  - znpy 6y ago
    Nah, Gitlab is the definitve solution. I really don't feel the need for anything besides gitlab + gitlab-ci.
amelius 6y ago
The logo looks like the USB logo.
stonesweep 6y ago
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/7f3515800bd8e693de8383b52adf09254b4fc1e5/ 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 -> https://kallithea-scm.org/repos/kallithea/pull-request/140/_/Incoming_changes_from_Andrew_used_on_https_//kallithea-scm.org/repos/ https://kallithea-scm.org/repos/kallithea/pull-request/140/_... (...which you can delete everything after /140/ and it works fine). Oy vey.
- cazim 6y ago
  >(...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/_/ThisProjectSucksDontUseIt-UseThisOneXXXXXX https://kallithea-scm.org/repos/kallithea/pull-request/140/_...
  - chrisshroba 6y ago
    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 https://google.com#you_should_use_bing_instead https://google.com#you_should_use_bing_instead
    - julianlam 6y ago
      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 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.
throwaddzuzxd 6y ago
Damn that's some ugly green. Too bad.
alfonsodev 6y ago
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.
- john_cogs 6y ago
  This page details GitLab's architecture: https://docs.gitlab.com/ee/development/architecture.html 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.
  - alfonsodev 6y ago
    thanks a lot!
- qbasic_forever 6y ago
  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 https://github.com/go-gitea/gitea
superkuh 6y ago
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?
- ericlewis 6y ago
  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
- hn_throwaway_99 6y ago
  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).
- dragonsh 6y ago
  > 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.
- DrBazza 6y ago
  > 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.
CraigRood 6y ago
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.
zoomablemind 6y ago
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/e6034764387ef53ca61374b152e6b08dc3373f4d https://kallithea-scm.org/repos/kallithea/changeset/e6034764...

198 points by dragonsh 6y ago

10000truths 6y ago

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

cooperadymas 6y ago
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.

gmueckl 6y ago

There's also Heptapod (https://heptapod.net 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.

quietbritishjim 6y ago

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

movedx 6y ago
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.
- dragonsh 6y ago
  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. 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.
  - LaGrange 6y ago
    > 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.
    - gmueckl 6y ago
      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 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.

MrGilbert 6y ago

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!)

junon 6y ago
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.
- codetrotter 6y ago
  > 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.
  - MrGilbert 6y ago
    > 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.
  - junon 6y ago
    They aren't saying "we can't fix this right now". They're saying, straight up, "this isn't a problem".

T3RMINATED 6y ago

gitlab is better

docsaintly 6y ago

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

muxator 6y ago
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.
- bjkchoy 6y ago
  These days RhodeCode has a Community edition which is licensed under AGPLv3.
tweetle_beetle 6y ago
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 https://kallithea.readthedocs.io/en/latest/readme.html [1] https://github.com/go-gitea/gitea/issues/458 https://github.com/go-gitea/gitea/issues/458 [2] https://github.com/gogs/gogs/issues/125 https://github.com/gogs/gogs/issues/125 [3] https://gitlab.com/gitlab-com/blog-posts/-/issues/261 https://gitlab.com/gitlab-com/blog-posts/-/issues/261 [4] https://www.gerritcodereview.com/roadmap.html https://www.gerritcodereview.com/roadmap.html
mro_name 6y ago
> contributing time and resources to awesome open source do you or do you just give grumpy advice how others should spend their own time?

dragonsh 6y ago

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.

tempest_ 6y ago
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.

apples_oranges 6y ago

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

k__ 6y ago
What's the difference?
- webmaven 6y ago
  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.
  - ptx 6y ago
    > 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?
    - moonchild 6y ago
      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.
steviedotboston 6y ago
yeah, "pull request" is terrible terminology. It confused me for years.

sneak 6y ago

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.

timw4mail 6y ago
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.

temp8964 6y ago

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

FpUser 6y ago
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.
- temp8964 6y ago
  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.
  - FpUser 6y ago
    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.
qbasic_forever 6y ago
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.

lelanthran 6y ago

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?

poisonborz 6y ago
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.
- lelanthran 6y ago
  Okay with anything, really. We're paying money for this no matter if it's open or closed. Thanks, will check it out :-)
- mxuribe 6y ago
  Oh wow, i remember YouTrack! I have not used it for about 5 years or more now. I used it as a client to a dev agency, and really enjoyed the experience. My understanding is that the client/guest view - at least back then - wasn't even the full cool experience...so from client side, YouTrack was absolutely great! I have never used it as a dev., so no idea what the difference is, or how things work for a dev., or if better/worse, or what. I even remember that for another agency that we had to work with, they choose Jira...and my peers and i all hated Jira...but we all loved YouTrack...again, back then - no idea if things have changed. Thanks for bringing back that positive memory of YouTrack!
elviejo 6y ago
also there is open source https://www.taiga.io https://www.taiga.io
nerdponx 6y ago
Maybe Taiga? https://www.taiga.io/ https://www.taiga.io/

znpy 6y ago

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.

kavalg 6y ago
Have you considered gitea + drone?
- gh-throw 6y ago
  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.
  - kavalg 6y ago
    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/ https://docs.drone.io/runner/exec/overview/
- znpy 6y ago
  Nah, Gitlab is the definitve solution. I really don't feel the need for anything besides gitlab + gitlab-ci.

amelius 6y ago

The logo looks like the USB logo.

stonesweep 6y ago

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/7f3515800bd8e693de8383b52adf09254b4fc1e5/ 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 -> https://kallithea-scm.org/repos/kallithea/pull-request/140/_/Incoming_changes_from_Andrew_used_on_https_//kallithea-scm.org/repos/ https://kallithea-scm.org/repos/kallithea/pull-request/140/_... (...which you can delete everything after /140/ and it works fine). Oy vey.

cazim 6y ago
>(...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/_/ThisProjectSucksDontUseIt-UseThisOneXXXXXX https://kallithea-scm.org/repos/kallithea/pull-request/140/_...
- chrisshroba 6y ago
  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 https://google.com#you_should_use_bing_instead https://google.com#you_should_use_bing_instead
  - julianlam 6y ago
    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 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.

throwaddzuzxd 6y ago

Damn that's some ugly green. Too bad.

alfonsodev 6y ago

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.

john_cogs 6y ago
This page details GitLab's architecture: https://docs.gitlab.com/ee/development/architecture.html 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.
- alfonsodev 6y ago
  thanks a lot!
qbasic_forever 6y ago
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 https://github.com/go-gitea/gitea

superkuh 6y ago

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?

ericlewis 6y ago
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
hn_throwaway_99 6y ago
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).
dragonsh 6y ago
> 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.
DrBazza 6y ago
> 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.

CraigRood 6y ago

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.

zoomablemind 6y ago

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/e6034764387ef53ca61374b152e6b08dc3373f4d https://kallithea-scm.org/repos/kallithea/changeset/e6034764...