Six weeks and about 90 commits after v0.11.0, git-bug v0.12.0 is available.
This is a maintenance release. There is no big new feature to show off, but there are a lot of bug fixes, and among them a good number of problems that had been open for years. Some of them go back to 2020.
Most of the work went into three places:
- the cache, largely rebuilt: there is no more repository-wide lock, and it now follows changes made outside of git-bug
- go-git, the git library git-bug uses, which needed many workarounds. If it has been getting in your way, git-bug can now use your
gitbinary for push and pull. - the git configuration, now handled by gitconfig, a new Go library that reads and edits git configuration exactly as git does. It lives in its own repository, so other Go projects can use it too.
Long-standing problems, resolved
- #409 (2020): the cache of a hosted repository was not updated when someone pushed to it
- #688 (2021):
branch config: invalid merge, for example with a branch created bygh pr checkout - #940 (2022): git-bug did not load your SSH configuration
- #1014 (2023):
the repository you want to access is already locked - #1022 (2023): git-bug rewrote
.git/configand dropped its comments - #1023 (2023): SSH did not work without an agent
- #1075 (2023):
git bug bug comment editopened an empty editor instead of the current comment - #1129 (2023): text validation let invisible and control characters through
- #1316 (2024): push and pull could not use different remotes
- #1402, #1475 (2025):
includeandincludeIfin the git configuration were not followed, so an identity configured that way was not found - #1416 (2025): authenticated HTTP(S) remotes did not work
- #1474 (2025): the deprecated
[section.subsection]syntax in a git config broke git-bug with an obscure error - #1485 (2025):
knownhosts: illegal base64 dataon push or pull - #1556:
git bug termuiheld a lock, and blocked every other git-bug command while it was running - #1589: a repository receiving a push only showed the changes once a git-bug command ran in it
The cache, rebuilt
The cache sits between the entities stored in git and everything else: the CLI, the terminal UI, the web UI, the bridges. It used to make two assumptions: that the process holding it is the only one touching the repository, and that nothing changes behind its back. Neither was true, and a lot of the bugs above came from there.
The command commits its change to git atomically, and updates that bug in the shared index. The web UI process notices the change in git, whether it comes from another git-bug process or from a git push. It reads what's already up to date from the index, rebuilds only what isn't and writes it back, and tells the browser through a GraphQL subscription.
Both assumptions are gone:
- no more repository-wide lock. Any number of git-bug processes can work on the same repository at the same time, safely. You can keep the web UI or the terminal UI open while using the CLI, or while an agent does (#1014, #1556).
- changes made outside are followed. The web UI and the terminal UI see a
git pushinto the repository, a pull, or another git-bug command, and show it shortly after (#409, #1589). They watch the filesystem where the operating system supports it, poll where it doesn't (network filesystems, for instance), and also compare every ref once a minute, as a backstop for anything those missed.git-bug.changes.notifierlets you choose, or turn it all off. - incremental repair. The cache records which commit each entity's derived data was built from, so on startup or on a change it rebuilds exactly what is out of date,
