michaelmure

Dev being reckless with LLMs are going to ship faster than the one using it responsibly to improve quality, so it would make sense to first see a drop in quality before things improve.

AI firm code are likely a different category though.

They would be two different bugs (even with the same title). Someone would recognize the duplicate and close one. That would happen less as the time to sync decrease.

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

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.

There is https://github.com/git-bug/git-bug/issues/63, but I have plenty to do before that.

It's really hard (impossible?) to define a feature set that work for everyone. Every bug tracker is a bit different, and if you want to have everything you end with Jira, which I'm not sure is actually solving a problem.

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.

Sure.

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.

The point of using git is to have a full software project (code, issues, ...) self-contained, without being trapped in or dependent on a SaaS, dead fast and working offline and integrating with all your tooling locally. All that with a single binary and git that virtually everyone use already.

Now what you are talking about seems to be about the lifecycle of a bug. With this model you can replicate the same behavior as on major bugtrackers, or also track some metadata (fix in commit xxx) and compute where the bug is "deployed". But that's a UX/social problem, not a technical one imho.

Fair enough, done!

Trust me, I'm an engineer

It's both really. If done well, the same local-first software can be a hosted solution and give you the "github" experience, or work fully locally, or anything in between with different topologies. If you work locally but care about some external sources, it's just a matter of notification, polling or transport. That can be done silently in the background.

I'll fix that soon. I really wanted to avoid calling the git binary for security reason, but I have to admit that go-git is not robust enough in some cases. I'll have at least the option to use the git binary for push/pull, possibly as a default depending on how it goes.

The choice to not use git merge handling was there from the beginning, the proper CRDT came a bit later when I understood more the problem and it's possible solutions. From a UX perspective, manually fixing merge conflict is the right thing for code, but it's a different story for social interactions: when the output you operate on is code, you want to precisely control that output. When the output is people understanding each other, you want to capture the intent. It's ok to, in rare case, be a little bit off in edge cases of the conflict resolution. What's not ok is forcing on the user to understand and deal with the problem.

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.

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.

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 :-)

Hi, author here, nice to see some interest :-)

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

Also, while there is some attention ... 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!

I want to do something like that with git-bug (keeping track of prompt/conversation/review alongside normal commit), but unsure what the DX would be. Insights welcome :)

In the same vein, but showing live the go allocator and GC operating on the heap of a running program: https://github.com/MichaelMure/gogc98

FWIW, I have a new and much better webui that I need to release. I'm also planning to work on PRs and other stuff around the end of the year.

I wish there was a LLM tool to explore a topic recursively, as a tree or a mindmap. You would start with some high level concept (say "cryptography") then dig further and further to more specific topics.

I think that would be a way more natural way to explore than being stuck on the classic linear output of a LLM.

That's an interesting take! Not quite easy to do with a CLI tool with dozens of commands though. Maybe it would be some kind of always on server the LLM can operate on ... but then that starts to really look like graphql.

I'm asking this because as I wrote a new CLI tool I picked json as the recommended output format for LLMs. I noticed though that they easily get lost and generally consume a lot of tokens to analyse the output. I'm sure it would work well when the LLM is trained for and already know what to expect, but that doesn't work for a new tool.

So, what's the natural language for them?

One nice upside of having a single way to encode a value is fuzzing: when you work on an encoder/decoder, you can use a fuzzer and do round-trip comparison until you find crashes or inputs/outputs that don't match (and therefore issues in the code). But with LEB128 for example, the fuzzer quickly learn about those alternatives encoding and there is not much you can do from there.

https://github.com/git-bug/git-bug if that's your thing.

Any recommandation for a quality non-toy rust codebase to study?

> On CRDTs: I assume tools like git-bug adopted CRDTs primarily to avoid merge conflicts, but "last-writer-wins" via timestamps is risky

FYI, git-bug doesn't use timestamps to figure out the ordering. It first uses the git DAG topology (it defines ancestors), then Lamport clocks (increment for any changes on any bugs), then order by hash if there is still an ambiguity. Note that the git DAG could also be signed, which would also provide some form of reliance against abuse.

I had an interesting discussion recently about how to handle conflict for bug trackers. In my opinion it's a great use-cases for CRDTs (as it avoids data corruption), as long as all user intents are visibly captured in a timeline and easily fixable. It turned out though that there is an interesting middle ground: as the CRDT captures *when* a concurrent editing happen, it's 100% doable to highlight in the UI which event are concurrent and might need attention.

Assuming that by "table" you mean another "document type" ... pretty easily. There is a reusable CRDT like datastructure that you can use to define your own thing. You do that by defining the operations that can happen on it and what they do. You don't have to handle the interaction with git or the conflict resolution.

> Stuff like git-bug exists, but then you still need participation from other people.

The plan is to 1) finish the webUI and 2) accept external auth (e.g. github OAuth). Once done, anyone can trivially host publicly their own forge and accept public contribution without any buy-in effort. Then, if user wants to go native they just install git-bug locally.

Location: France

Remote: Yes (have been 100% remote for 6+ years)

Willing to relocate: No

Technologies: Go, networking, protocols, identity, cryptography, local-first, CRDTs, devops, AWS, kubernetes, IaC, free software, linux

Résumé/CV: see my Github profile for notable and open source work: https://github.com/MichaelMure

Email: on my Github profile

I'm a builder, a backend engineer with strong go proficiency, passionate about local-first and how we can build better software for a better world. Happy to talk about opportunities.

With some motivation you could port git-bug to another VCS without too much problem. You would need to implement those interfaces [1]. The one you care about especially is RepoData, which mainly imply you can store a DAG, have references and push/pull. I believe other VCS (say mercurial) have similar concepts.

Or you could just as well plug a generic database there.

[1]: https://github.com/git-bug/git-bug/blob/master/repository/re...

Right now, yes, but the idea is to augment the webUI with external auth (e.g. Github OAuth and others) to make it a public portal where anyone can create issues and so on. In that case, the webUI would have access to the git repo, enforce any rules and prevent abuses.

With a single binary deployment, you'd just need a bit of config and a DNS, and you could host a forge-ish for your project.

We are not there yet but it's really not far.