Posted by alentred 10 hours ago
FYI, this is my near-term roadmap:
- have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions
- have the webui expose a git remote endpoint
- slightly rework identities (and likely root them in did:plc for pubkey distribution, the identity system from bluesky, without being an ATProto thing), which would allow to share identities between repos way more naturally
- extend to support pull-requests, possibly CI. That would make it a somewhat complete local-first forge that you can also self-host trivially
Make it easy for non-technical users to also use this software. That will probably get you further along with gaining paid customers, IMO, because that's the hard part with something like this. It's easy for anyone who isn't used to `git` to use GitHub issues or something like Jira or Shortcut, but something tied to `git` or another cli tool is a hard sell for non-programmers, I think.
Make a program users can install on their MacOS/Windows desktop that interacts with a repository, without any need for the user to use `git`, or make a secure/hardened docker image that an org can run in their infra that links to repos and allows interaction via the web.
> 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!
Don't sell to developers for their day jobs, but sell to developers for their hobbies.
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!
Identities in git can barely be called that. You define your name and email, maybe sign your commit. Those signature can be checked but it's really optional and often left to another system (e.g. github or your git viewer). Access right in the git remote is also a completely different thing.
In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates. Any changes in the entities (bug, pr, ...) need to have an author and a clear logical time so that you can backtrack to which pubkey(s) was active at the moment. Note that if you accept external contribution from a webui, you still need those identities being created in the background, possibly later to be "adopted" when using the native tooling.
Identities in git-bug is a part that nearly didn't change since the inception, and it's time for an upgrade. At the moment they are a linear series of changes (that is, NOT a CRDT) and are stuck within one repo. You can push/pull around but you are really just making a copy that you need to maintain.
My plan is to split this concept in two parts: pubkey log, and how they anchor within the repo's logical time. It turns out that if you split that way, the first part is pretty much exactly what did:plc is. Additionally, for complicated reasons like allowing recovery without opening major weakness, that's the one thing where having a centralized reference is important, so relying on the public https://plc.directory/ makes sense.
I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
> so that you can backtrack to which pubkey(s) was active at the moment
I think GitHub solves this by simply checking at the time of the push and then never again (which is why you can change the keys without de-verifying older commits. Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
---
https://web.plc.directory/ looks interesting, never heard of it.
Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
There is different pieces that solve part of the problem (name/email from the git config, key servers for *some* users), but everything is disconnected, unstable, incomplete. Git-bug needs a stable identifier, the full self-certified pubkey log ... Those solutions are not good enough.
> Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
It's not specific to git, but yes you get a chain of data blocks, content-addressed with signature support. That's what you want to build on, to have identities, roles, rules to enforce in a p2p system.
> Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
Agree! Note that if git-bug bring a solid identity primitive and publish pubkeys ... it can also carry the pubkeys that are *already* used to sign commits, publish them in the same public registry and verify code commits transparently, without relying on a third party to do so. Imho that's something missing in the current git model: if there is identities, there are segregated in third party systems like github. DIDs brings a lot to the table.
However, git-bug's data model is designed in a way that you can add more "operations" on an entity (say: assign a bug) without every client having to implement it. You can also add your own entity type (pr, kanban, ...) the same way. Clients will just ignore that extra data and support what they want. This open the possibility for addons and so on.
For this specific case of the bug states, I want to add a config entity to configure that. You'd start with a reasonable default (open/close) but you could tune it for the needs of your project.
I've long felt that something like this was the way but have never gotten around to working on it.
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.
Something like "scoped labels" https://youtu.be/7l7tnEva6I8?is=InYAVXHomobvbOjL
:thumbsup
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".
Note that this very question is why some previous attempt at distributed bug tracker failed.
As for the postmodernism of git, I don't know ;-). I'm simply building on top of the lower level git database and leveraging the tools I have (like push/pull). Each bug is essentially its own namespace of operations that get moved around between repos. As with any CRDT, the state of that document get built from what is known at the time.
There is a workaround, but it isn't pretty. You can push/pull bugs and identities with normal, ssh-agent-less git commands: https://gist.github.com/parasyte/80ef925d4b01216f6bcb051356f...
Specifying identify files for specific hosts, using bastion hosts (ProxyJump), etc. For example, my laptop SSH config detects when I'm not on my university network or VPN and adds a ProxyJump through the department bastion host, but connects directly when I'm on the network. Configurations like that break when software makes too many assumptions about how ssh is configured.
I use a Yubikey for some of my keys, and I've never used an "agent", don't know how, and don't want to start, unless someone can give me a good reason to
ssh-keygen -t ed25519-sk
that's all you need to use a Yubikey with SSH
also, don't know a good security researcher who uses agents (some even use ssh config to limit which keys are even tried per domain)
ssh config hacks are also a must if you have, say, two or more identities to github.com for example.
https://github.com/google/git-appraise
I used git bug before but found I missed being able to edit tickets with a Markdown editor. So I built this: https://github.com/LoumTechnologies/ticketry
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.
I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw
My comment on there is about a surge in popularity of these over a decade ago, with a link to a previous comment about problems I remember them having that prevented them from being usable for most people ( https://news.ycombinator.com/item?id=47956979 ), because of their intended design rather than an implementation issue. For example bullet 3 was a problem in one, that another tried to solve with bullet 2.
I don't have time right now to look at this one to guess if these apply, but might be interesting/useful for someone 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.
- If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed
- I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch? Is it on the reporter to correctly identify the root branch where the issue was first created? Do you have to somehow merge to make this work "right"?
> - If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed
I do not have a solution for that.
> - I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch?
The idea was to create issues only on on a separate branch which is constantly merged into master. Then all branches downstream of master will get the issue when they rebase/pull.
Scenarios:
1. You're on branch `x/y/z`, you notice something that should be added to the issue tracker, you stash, switch to `/issues`, add the issue, push, switch back to `x/y/z` and pop.
2. An issue is to be created, the creator clones `/issues`, creates the issue, and pushes.
This way, all issues are on all branches, but only the branch dealing with an issue will update it.
It's human-readable, simple, and easy to work with. Basically there's no magic.
(Excuse the vibe-coded README)
Anyway, even though I’m using it every day, I’m beginning to doubt the core idea of tracking hundreds of .md files in git. They get in the way of fuzzy file search, and if you keep closed tickets around in an archive directory, they just pile up endlessly.
Lately I’ve been considering breaking tickets out of VCS entirely or moving them to a dedicated repository just for ticket tracking.
Git bug looks like it might at least handle getting tickets out of the way
See, at core git is a collection of objects (referenced by their hash), along with references to tip-of-tree objects. These references are stored in the refs/ directory, and core git only uses a couple subdirs/namespaces under that: refs/heads/ (for branches) and refs/tags/ (for tags). Git also bundles the oft-forgotten git notes command that stores notes in refs/notes/. But you can add whatever other name under refs/ to tack on whatever functionality you want, which is what all these git-based bug-trackers do.
Side-note, Gerrit exploits this wide-open namespace for its behavior, where pushing to the virtual refs/for/ namespace will create a new Change destined for a given branch. It also uses these namespace for its internal NoteDB.
Looks great by the way.