Grebedoc is Codeberg spelled backwards. I find this name very clever, especially since it has “doc” in it (static site hosting can be used for Markdown Documentation|documentation).
This is a new option for Static Website Hosting, which can serve as an alternative to GitHub Pages. Codeberg already a similar solution called Codeberg Pages, though Codeberg Pages had a big scary warning that says it is in maintenance mode. Grebedoc is using new software, git-pages, so does not rely on Codeberg/pages-server (which is the part of the Codeberg Pages stack that is in maintenance mode).
One of Grebedoc maintainers here! I came up with the idea for Grebedoc (and its underlying software, git-pages) when I realized that I have an extreme degree of dependency on GitHub Pages from many years of using GitHub, but it also seemed pretty likely that sooner or later, GitHub will stop subsidizing my efforts one way or another, and I need a backup plan.
I originally wanted to just use Codeberg Pages, but it had some significant scaling and uptime issues (that I don’t want to rehash here). I ended up concluding that the reasonable way forward is a redesign, which is what I’ve built and deployed with a small team of other volunteers. It took about a month of work and the whole thing, anycast and all, costs about 35€/mo to run. Also, Codeberg Pages is currently trialing the use of git-pages as the new pages backend, and you should be able to use it on the *.codeberg.page domain already (it responds to the same POST/PUT requests as Grebedoc)/
The fact that the entire global stack “costs about 35€/mo to run” is impressive. Though, I wonder what the increase in cost will be when more people start using Grebedoc.
One of my concerns was that Grebedoc sites would have to use a Codeberg repository. Codeberg looks good, though it is more limiting than GitHub or GitLab since they require every repo to use an open source license. This also raises concerns when creating a website/blog of my own, will any content hosted on a Codeberg repo also have to be licensed for the public domain?
However, based on grebedoc.dev, using Codeberg is not mandatory. There is a small learning curve to understanding how to host a site on Grebedoc, but the main page explains different scenarios clearly. There is a size limitation:
The size of a website is currently limited to 1 GiB. We are aiming to eventually raise this to 10 GiB.
UPDATE: Originally, the size limit was 768 MiB, but this has recently been raised to 1 GiB.
Based on all of that, it looks like I should be able to host small websites (up to 1 GiB) on Grebedoc, no matter which Git forge I choose to use and the repo can also remain private. I can use my own domains if I want, though Grebedoc also allows using *.grebedoc.dev or *.codeberg.page subdomains. All of this is free, as far as I can tell there is no paid-tier (Codeberg is a non-profit, they can be supported, but this is not required for using anything they offer).
A pre-commit is a type of Git Hook that runs before each commit. It can help with verifying code standards (linting, formatting, testing etc.).
A tool written in Python, though can be used with projects in any language. Can be configured to run many hooks including pre-commit/pre-commit-hooks and Gitleaks. I have used this tool and like it for Python and other projects, though for Node.js projects, I prefer the options below.
A pre-commit hooks tool written in JavaScript. I prefer this tool for Node.js projects since it can be easily integrated in package.json scripts.
Another tool that’s written in JavaScript, to help run checks against staged files (see Guide below). Lint-staged does not configure git pre-commit hooks on its own, but can be combined with Husky.
Another git hooks manager written in JavaScript. Use to be more lightweight than Husky, but newer versions of Husky closed the gap.
Configure oxlint and oxfmt based on my Oxc Workflow.
Install devDependencies:
npm install --save-dev husky lint-stagedhusky:# Installed
./node_modules/.bin/husky --init# Not installed
npx run husky --initlint-staged to run Oxc and tsc checks:[/**
* @filename: lint-staged.config.js
* @type {import('lint-staged').Configuration}
*/
export default {
'**/*.[jt]s?(x)': [
'oxfmt',
'oxlint --type-aware --type-check --fix',
],
'**/*.ts?(x)': () => 'tsc -p tsconfig.json --noEmit',
}Can be further configured, but this is a good start for a project using TypeScript and Oxc.
husky to run lint-staged as a pre-commit hook:npm exec -- lint-staged --config lint-staged.config.jspreparescript in package.json : "scripts": {
"prepare": "husky"
},husky --init.
Setting up Git correctly on both Windows and WSL is essential for a smooth development workflow, especially in environments where you switch between the two.
.gitconfig files between systems.Follow these steps to install Git, configure it properly, and enable seamless authentication across both environments.
These commands all need to run in Windows PowerShell.
winget install -e --id Git.Git --source=wingetIf you need Git LFS, also run the following command:
winget install -e --id GitHub.GitLFS --source=wingetgit --version; git credential-manager --versionIf you are using GitHub, you can use your GitHub username and the “no-reply” email address from GitHub Email settings.
$env:GIT_EMAIL = "your-git-email"$env:GIT_USER = "your-git-username".gitconfig
These settings help avoid common git warnings.
git config --global color.ui "auto"
git config --global init.defaultBranch "main"
git config --global user.email "$env:GIT_EMAIL"
git config --global user.name "$env:GIT_USER"These commands all need to run in WSL.
sudo apt-get update && sudo apt-get install git git-lfsgit --version && git lfs --version.gitconfig file from Windows
cp "$(wslpath -a "$(cmd.exe /c ")")" "${HOME}/.gitconfig" git config --global credential.helper "$(wslpath -a "$(powershell.exe -NoProfile -Command "Write-Host -NoNewline (Join-Path ((Get-Item (git --exec-path)).Parent.Parent.FullName) 'bin\git-credential-manager.exe')")")"Featured image by Gabriel Heinzer on Unsplash.
]]>forgeperf.org is maintained by SourceHut, who are not impartial. SourceHut just so happen to lead most of the performance results. I can believe that the benchmarks are accurate, though the benchmarks may have been designed in a way that favors SourceHut.
Even so, performance is not everything. SourceHut’s UI is noticeably basic, which might be good for performance but not necessarily the most pleasent to use. SH patchsets are sent over email, an antiquated workflow (even if it’s still how Linux kernel development works).
The reasons I dislike Bitbucket have little to do with its subpar performance. Bitbucket, like most of Atlassian’s suite, just feels aggressively average. I wouldn’t go as far as to say Bitbucket is bad, it functions fine as a git forge. It does the basics decently well and many enterprises successfully use it. However, when compared to its main competitors, Bitbucket feels objectively worse. It kind of sucks.
I would consider the main competitors to be GitHub and GitLab. Both of these have many more features than Bitbucket. Bitbucket is falling behind and playing catch-up, slowly implementing features that the competitors had years ago. Here are several examples.
There was a recent announcement of Bitbucket Packages. This will be Bitbucket’s own solution for an artifact registry, starting with a container registry. GitHub and GitLab already had artifact registry solutions for years, for example GitHub launched GitHub Package Registry in 2019 and GitHub Container Registry in 2021. Even when Bitbucket Packages does launch it will be limited to containers only at first. I also noticed that Bitbucket is missing a Releases feature, which both GitHub and GitLab have.
Atlassian has had several different CI/CD solutions over the years. Bamboo used to be the main one, and many companies used (or still use) a Bitbucket+Jenkins combo. Nowadays, Bitbucket Pipelines is the main solution that Atlassian tries to push onto its customers. One of these customers is my current client. I came into the client having to deal with the hacky Bitbucket pipelines that the previous team left me. We are using self-hosted Bitbucket Runners running on EC2 instances, because the hosted Bitbucket Runners are underpowered. Overall, I got the pipeline working, although the entire time I wished I was using GitHub Actions instead. To be fair, it’s clear Bitbucket Pipelines is being actively developed and is getting new features. However, it’s also clear that it’s playing catch-up against others CI/CD solutions (including GHA and GitLab CI/CD). There are all sorts of weird limitations, some of which have been fixed and others which still haven’t. For example, until recently, Bitbucket Pipeline steps were limited to only 2 hours. This has thankfully been fixed, and now the max-time can be set up to 720 (12 hours), enough to most (but not all) jobs. Other limitations continue to exist. GitHub has the Actions Marketplace full of community actions that can be easily integrated into GHA workflows, often completely for free (many actions are FOSS). Bitbucket works with the Atlassian Marketplace and Bitbucket Pipes integrations | Bitbucket, but this is much more limited and harder to use with Pipelines, and the majority of Apps are paid.
I was excited about SSH commit signature verification this feature when I learned about it during my bootcamp in late 2022. GitHub was quick to implement it and GitLab not long after. I then started working with clients that used Bitbucket and was surprised to find this feature missing! Only in 2025 did Bitbucket Cloud release SSH commit signature verification, more than two years after both GitHub and GitLab.
Bitbucket has no official CLI tool in the style of GitHub CLI or GitLab CLI. Of course, the standarad Git CLI does work well with Bitbucket, but the gh and glab CLI tools go beyond that and allow to do many actions directly using commands. Bitbucket does have REST APIs (The Bitbucket Data Center REST API and The Bitbucket Cloud REST API) which do work, but are harder to use than an equivalent CLI tool would be.
GitHub has Codespaces and GitLab has Workspaces. Both are Cloud Development Environments based on VS Code. Microsoft maintains both GitHub and VS Code. VS Code itself remains open source under the MIT license. GitLab maintains their own VS Code fork.
Bitbucket offers to use Cloud IDE add-ons Bitbucket Integrations, but doesn’t have anything built-in.
Dependabot is built into GitHub. GitLab uses Renovate GitLab Bot. Renovatebot can work with Bitbucket, either self-hosted or supported by Mend, however there is nothing built-in to Bitbucket.
A major point of confusion for me when using Bitbucket has been the the differences between Bitbucket Data Center and Bitbucket Cloud. While both look like Bitbucket, they are essentially two different products with different features and development cycles. Every time I look up Bitbucket documentation, I have to make sure that I am following docs for the right product. There are even two different Bitbucket REST APIs.
In comparison, GitLab operates under a single codebase for Community and Enterprise editions and the same codebase is used to run GitLab.com:
The largest known GitLab instance is on GitLab.com, which is deployed using our official GitLab Helm chart and the official Linux package.
Bitbucket Server reached end of support in 2024. My clients at the time were already using Bitbucket Data Center so they weren’t affected. However, Bitbucket recently announced that Data Center will reach end of life in 2029. The solution going forward will be only Bitbucket Cloud. While this solves the fragmentation problem, it does so at the expanse of any self-hosted solutions. I believe there are still organizations for whom self-hosting is non-negotiable. Atlassian is essentially giving up on these customers. Perhaps they’ve done their cold calculations and decided that continuing to develop and support Bitbucket Data Center is no longer worth it even if they do lose some customers.
Meanwhile, GitLab continues to to offer a self-hosted solution, that can even run for free with GitLab Community Edition. GitHub offers GitHub Enterprise Server.
Featured image by Courtney Moore on Unsplash.
]]>