Who knows how many things GitHub does are actually embedded into git itself :)

Someone is taking lessons from fossil-scm.

Looks great by the way.

Their logo is a ladybug so everything works out in the end.

Although if it doesn't get fixed, it also sometimes becomes a feature.

There’s also Fogbugz, Mantis Bug Tracker, etc.

Don't overthink it! `git bug bug` is fine - it's easy to type and becomes muscle memory quickly. Love the project, my first impression is "why hasn't this existed the entire time?" which usually means you're on to something.

Lack of a feature is a bug. After all, it's intended functionality that doesn't work!

It's also a denial of service, since the feature doesn't work yet, and thus should get assigned a CVE.

A quick checks shows that it seems so, last month. No answer to the RFC yet, though.

excellent! will definitely give this a try

The issue there was collaboration, one person would be on master and see no hint that a case was already being worked on (status, comments, etc all being different until the branch was merged). The other bullets, that put the information in different locations, were attempts to deal with this.

Well written blog post! I enjoyed reading it.

No mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.

It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.

Git-bug looks amazing! Author of GitSocial here, would love to hear your opinion:

https://gitsocial.org/

Yeah I agree that monetization seems hard here. But one niche that might work - tons of people are using LLMs to build out side projects and keeping tickets in the same repo as the project could be really frictionless for LLMs to reach for without an MCP server.

Don't sell to developers for their day jobs, but sell to developers for their hobbies.

Any thoughts to making this integrate alongside other systems that use git metadata to track changes?

I'm thinking mostly of Gerrit, which keeps the entire code review and change history in git as well.

Being able to keep literally everything in the same git repo seems highly appealing.

- have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions

Have you looked into ForgeFed? It's a WIP plan for different Forgejo based forges to federate with each other. https://forgefed.org/

There's also this: https://indieauth.net/ though I haven't looked into it. I hope you could integrate one of these into your planned OAuth/account system!

It's deeply interesting to me that you decided to override git conflict-resolution (at least in the 90% of cases) in favor of CRDT conflict-resolution. That sort of decision is not uncommon but I was just kinda wondering -- did the CRDT idea come first or did you try a plain-text format for storing the bugs and you ran into certain common workflows where that wasn't ergonomic? (My first guess would maybe just be appending comments to the ticket -- so like if a ticket is a TOML file, you both append a comment at the end, Git immediately screams about what order should those two comments be in -- instead to make that ergonomic within Git's limitations you have to like, represent the comments as a directory tree with no inherent order and UUIDv4 names, and then Git will say "oh you both put blobs in that tree? that's fine. no conflicts," and then you have to order them by (declared-time, UUID) on the client side.)

What's not quite so clear from what I'm skimming is what you did to alleviate Git's postmodernism. What I mean is, Git just holds a bunch of refs like tags and branches and they all deliberately, inherently have equal valence -- this comes from the history of Linux being developed on an email list, there literally is not "one Linux", there is no truth about "what is the Linux v6.18 kernel" but rather there is a big family of v6.18 Linux kernels and anyone who wants to spin up a new one can literally just grab an existing v6.18 kernel and write a patch and bam, you have a new one. It's the blind sages and the elephant, every sage is correct about what the software is, within their limited ability to perceive what the software does. And this like perennially causes problems, right, people use Git for a modernist thing like CI/CD where at most companies "what's running in prod?" is one of those questions that we don't like to say "well it depends on your perspective, there is no one truth..."

Sorry for the long explainer -- I'm just aware that this is a very idiosyncratic way of phrasing the D in DVCS. But it's like, in concrete terms, do you have clients force themselves to declare a certain repo as their origin, and a certain ref on origin is the blessed Git-Bug ref that they have to push from and pull to? And like the add-on that you've crafted just doesn't let you branch the ticket list and all of that? Or -- the opposite -- do you go all-in on the postmodernism and say "no whether some strange-looking functionality is a 'bug', that is a fact that needs to be added to the holistic perspective of the project, and whether that bug is deemed fixed is a similar fact that, like, if you say you fixed the bug in `dev` it might still be not fixed in `uat` or `prod` -- so the bugs need to be stored in the repo that you're versioning anyways. And we use these CRDTs to give you a bird's eye consistent view of a Bunch of repos and all of their current statuses and all that." Or do you take a third direction that's neither purely modernist "this is the truth" nor purely postmodernist "every branch is true".

For your roadmap, it would help with collaborating and organizing to use the issue queue

Something like "scoped labels" https://youtu.be/7l7tnEva6I8?is=InYAVXHomobvbOjL

The webui supports markdown

Wouldn't it require constantly pushing/fetching? Or would it effectively be like a hosted thing with a service layer on top of git showing a live view of the repo's tickets? Like github but for tickets... oh wait...

well then you aren't using this project

This is a really cool project, and I would love to see Magit add support for this. I do have one constructive criticism though, take it or leave it.

I would not say git-bug is "embedded" in Git. It follows Git's command naming convention, so it is resolved by the Git cli if it is found on $PATH. I would say that git-bug integrates with git's workflow and uses git's storage. I think it would be less confusing if the claim were: git-bug is fully integrated with Git, or something similar to that. To say that it is "embedded" implies that the binary is loaded through a plugin or extension mechanism more directly than a command-convention lookup.

I considered using something like this, but instead I implemented my own basic JSONL issue tracker, and I keep the issue files in an `issues` branch in Git. This separation of concerns allows simpler design and gives more flexibility (if I want to change either git or the issue tracker, or go without Git altogether, they're not tied together).

Over the years I've noticed that "merging two designs into one" is a design smell. Nearly every technology we still use today has a very clear separation from other technologies, and is instead layered or composed to gain added functionality.

Isn't "show stopper" a bit dramatic? What is the big problem with an SSH agent? If security is a problem you should probably store your SSH keys on a HSM like a Nitrokey or Yubikey. In which case you need an agent.

My favorite VCS friendly ticket tracker is https://github.com/wedow/ticket

It's human-readable, simple, and easy to work with. Basically there's no magic.

There is a certain appeal to not depending on more tools, and there is something elegant about the bug list traveling with revisions, if they are closed when the bug is fixed. So at any point you could go backwards and see known bugs at the time.

This also applies to certain project management flows and statuses.