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

:thumbsup

First of all: Huge respect for getting something out the door, looks really useful.

> I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!

You could consider an "enterprise" tier with a special subset of features and guaranteed support. But my experience tells me this will be really hard to substantially monetize, as the customer profile for that solution is probably not spending on software until they really need to (the saying goes: selling to developers is impossible, you need to sell to their boss). Maybe a donation model or a creator-centric thing could work out!

> - 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!

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.

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

https://gitsocial.org/

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".

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.

The webui supports markdown

And none of them actually work really well. This blog post is over ten years old, but the situation didn’t improve much https://matej.ceplovi.cz/blog/current-state-of-the-distribut...

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.

Other than the first bullet point in your list[1], my contribution in this regard addresses everything else.

Don't have a link handy but it's on github called "rotsit" (revenge of the something issue Tracker).

‐----‐------

[1] That's the entire point of having the issue tied to a branch: if an issue is marked resolved in the branch you are looking at, then its resolved in the branch you are looking at. Storing the issues independent of branch means you need to also store extra metadat about which branch it is broken on.

Wow! Was this sent upstream to cgit?

do one thing and do it well...

I agree. I'll have soon-ish the webui accept OAuth/OIDC, so you can easily host and replicate a normal bug tracker experience... yet still benefit from the other workflows that a normal forge can't have.

That's the key feature to make a distributed bug tracker actually work in practice.

Bugzilla has been using the term "bug" to track features for nearly 3 decades now. Doesn't seem to hamper them.

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.

I do want to extend to pull-request and more, so I'll need to at least make space in the CLI commands. Having a "git bug bug" next to a "git bug pr" is quite ugly.

Naming is hard, but I mostly didn't expect to reach that point :-)

Isn't everything nowadays a bug?

Only once it gets fixed does it become a feature.

;)

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

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

Then your repo probably has bugs?

well then you aren't using this project