Our great sponsors
-
AECforWebAssembly
A port of ArithmeticExpressionCompiler from x86 to WebAssembly, so that the programs written in the language can run in a browser. The compiler has been rewritten from JavaScript into C++.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
The problem with GitLab is that, between their plan to delete inactive repositories (hopefully abandoned) and their constant price hikes, they seem to do everything to destroy customer trust.
That could be true. I host my AEC-to-WebAssembly compiler on GitHub, GitLab and SourceForge, and it's only on GitHub that it has 21 stars and 2 forks. On GitLab and SourceForge, it has zero of both.
That could be true. I host my AEC-to-WebAssembly compiler on GitHub, GitLab and SourceForge, and it's only on GitHub that it has 21 stars and 2 forks. On GitLab and SourceForge, it has zero of both.
Where this gets obnoxious is: Even if you did all that, someone will push your project to Github whether you do or not, and it'll attract a ton of attention and contributors, and those contributors will all click on the "issues" tab or the "pull requests" tab. People have sent tons of pull requests to https://github.com/torvalds/linux, even though the Linux kernel is notable for still using mailing lists for all dev work.
For example, there's a bunch like bug, where the issues just get stored as plaintext files in your repo. This makes intuitive sense -- it's like storing your docs as Markdown files in your repo. You can use all the same tools to branch and merge and such, and you can include some code that fixes an issue, mark the issue as fixed, and update the docs all in the same commit, without needing any special tooling to synchronize those things. If you want to find out which branches (or releases, etc) have the fix, you can just look at the state of the bug inside those branches.
Probably git-bug is closer to what Fossil does: It uses Git as a storage engine, and can coexist with your code in the same physical repository, but the issues don't actually show up as source files. Instead, each issue is a special branch (buried in refs so it won't clutter up git branch) that has zero common ancestry with anything else. So in theory you can poke at it with Git, but really, the Git under the hood is mostly an implementation detail, and as long as you interact with those files through the tool, it guarantees you won't have merge conflicts.
It was mostly Opera Critic that I was referring to. Few know about it, its user base is very small, and it does not get very much love. It can be cumbersome to work with, and it hasn't changed much in the last decade, but it is still superior to GitHub and GitLab for certain use cases (especially large code refactoring branches).
> If you want to look into people who disagree with you: https://forgefed.org/