[HN Gopher] Kallithea - Self-hosted alternative to GitHub
___________________________________________________________________
Kallithea - Self-hosted alternative to GitHub
Author : dragonsh
Score : 180 points
Date : 2021-04-06 08:13 UTC (14 hours ago)
(HTM) web link (kallithea-scm.org)
(TXT) w3m dump (kallithea-scm.org)
| MrGilbert wrote:
| 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!)
| dragonsh wrote:
| 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/
| pokstad wrote:
| Git also has git-web and gitk for local GUI usage.
| nurb wrote:
| Not to forget git gui, that allow you to pick lines to
| commit instead of the whole file
| c0l0 wrote:
| So does git add --patch [FILE...]
|
| btw (by invoking your $EDITOR).
| scambier wrote:
| 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.
| Conan_Kudo wrote:
| 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
| boogies wrote:
| (Offtopic) You can simplify [2]-[5] to just 1.
|
| 1https://repology.org/project/pagure/versions
| knuthsat wrote:
| This looks great!
| jetpackjoe wrote:
| Is there a good git -> fossil tutorial/migration guide?
| bovermyer wrote:
| Fossil itself has a decent translation guide:
|
| https://fossil-scm.org/home/doc/trunk/www/gitusers.md
| junon wrote:
| 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.
| Jnr wrote:
| 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.
| [deleted]
| kdumont wrote:
| 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!
| hnjst wrote:
| 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!
| codetrotter wrote:
| > 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.
| junon wrote:
| They aren't saying "we can't fix this right now". They're
| saying, straight up, "this isn't a problem".
| freeopinion wrote:
| Pictures or it didn't happen. One of the maintainers has
| responded specifically to you here and you have ignored
| their outreach.
| oarsinsync wrote:
| > 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.
| MrGilbert wrote:
| > 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.
| knorker wrote:
| 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.
| MrGilbert wrote:
| 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.
| halayli wrote:
| why not use github private projects? It's free.
| mro_name wrote:
| without liability but with TOS. LOL, srsly?
|
| What's that good for?
| Proven wrote:
| Wut? Liability for what? Me using their free service?
|
| I don't pay anything so I don't expect any commitment or
| compensation in the case they fail to perform.
|
| > What's that good for?
|
| It's good for online source code repo, CI/CD and other
| workflows, documentation hosting, project docs, project Web
| site, issues, Wiki, discussions, MFA and few other things.
| Pretty good value for money.
| nsb1 wrote:
| Because https://news.ycombinator.com/item?id=26709159
|
| ..which is unfortunate.
| [deleted]
| zrail wrote:
| 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.
| orblivion wrote:
| I just set this up and I'm quite happy with it. I did not
| know about wildcard repos, I'll check that out.
| beeforpork wrote:
| > 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.
| whydoineedthis wrote:
| > 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?
| eknkc wrote:
| > 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?
| edgyquant wrote:
| 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.
| loloquwowndueo wrote:
| 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/ :)
| Certhas wrote:
| 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...
| GuB-42 wrote:
| 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.
| miohtama wrote:
| It's almost like git was written by kernel programmers who
| knew only C and Perl.
| kstrauser wrote:
| 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.
| agateau wrote:
| [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
| xorcist wrote:
| 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.
| beeforpork wrote:
| > ... 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.
| qbasic_forever wrote:
| 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.
| onedr0p wrote:
| You could put gitea in a container and limit it's resources,
| what benefits does a bare metal install give you?
| onedr0p wrote:
| Ignore this, not sure what your issue with those apps are
| saagarjha wrote:
| 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.
| MrGilbert wrote:
| > 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.
| robertlagrant wrote:
| It makes sense that most distributed version control system
| features wouldn't apply to a single user.
| lordgroff wrote:
| For issues, there's git-bug:
| https://github.com/MichaelMure/git-bug
| MrGilbert wrote:
| That's nice, thanks!
| DrBazza wrote:
| > 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?
| tekstar wrote:
| 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
| superkuh wrote:
| 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?
| dragonsh wrote:
| > 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.
| sdfzug wrote:
| I must admit there is a use case for something like that,
| though I also must admit that I personally feel the same
| DrBazza wrote:
| > 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.
| qbasic_forever wrote:
| 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).
| qbasic_forever wrote:
| 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.
| ericlewis wrote:
| 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 wrote:
| 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).
| lelanthran wrote:
| 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 wrote:
| 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 wrote:
| Okay with anything, really. We're paying money for this no
| matter if it's open or closed.
|
| Thanks, will check it out :-)
| nerdponx wrote:
| Maybe Taiga? https://www.taiga.io/
| elviejo wrote:
| also there is open source https://www.taiga.io
| alfonsodev wrote:
| 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 wrote:
| 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.
| qbasic_forever wrote:
| 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
| stonesweep wrote:
| 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.
| cazim wrote:
| >(...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/_...
| chrisshroba wrote:
| 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
| julianlam wrote:
| 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.
| znpy wrote:
| 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 wrote:
| Have you considered gitea + drone?
| znpy wrote:
| Nah, Gitlab is the definitve solution.
|
| I really don't feel the need for anything besides gitlab +
| gitlab-ci.
| gh-throw wrote:
| 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.
| T3RMINATED wrote:
| gitlab is better
| gmueckl wrote:
| 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.
| amelius wrote:
| The logo looks like the USB logo.
| docsaintly wrote:
| So instead of contributing time and resources to awesome open
| source alternatives that already exist, we have yet another
| competing offering. Awesome.
| jitix wrote:
| 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.
| muxator wrote:
| 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 wrote:
| These days RhodeCode has a Community edition which is
| licensed under AGPLv3.
| tweetle_beetle wrote:
| 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
| mro_name wrote:
| > contributing time and resources to awesome open source
|
| do you or do you just give grumpy advice how others should
| spend their own time?
| zoomablemind wrote:
| 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...
| apples_oranges wrote:
| 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).
| steviedotboston wrote:
| yeah, "pull request" is terrible terminology. It confused me
| for years.
| k__ wrote:
| What's the difference?
| webmaven wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| 10000truths wrote:
| How does it compare to existing solutions like Gitea or gerrit?
| cooperadymas wrote:
| 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.
| throwaddzuzxd wrote:
| Damn that's some ugly green. Too bad.
| sneak wrote:
| 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 wrote:
| 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.
| quietbritishjim wrote:
| One big benefit of Kallithea is that it supports Mercurial
| repositories.
| movedx wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| dragonsh wrote:
| 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_ wrote:
| 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.
| temp8964 wrote:
| How does any of those similar solutions solve the data backup
| problem? I always think GitHub / GitLab also serves as an off-
| site backup.
| qbasic_forever wrote:
| 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.
| temp8964 wrote:
| 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.
| FpUser wrote:
| 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 wrote:
| 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 wrote:
| 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.
| CraigRood wrote:
| 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.
___________________________________________________________________
(page generated 2021-04-06 23:01 UTC)