Live data from Hacker News

Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

github.com

91–100 of 110 posts

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#91
I personally hate how all these platforms like GitHub, GitLab, BitBucket, etc slapped a centralized relational database to manage issues, comments, merge requests, etc next to a distributed de-centralized system like Git.

I especially hate how they've integrated CI/CD into the Git platforms.

I loathe the fact that Microsoft has tied their AI to their Git platform.

I want my CI/CD to be agnostic. I want my AI to be agnostic. I want my issues, MRs, comments, etc to be decentralized and come along for the ride when I clone a repo.

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#93
post #84

Earlier quoted context omitted.

> "Why would you do it any other way" would be more interesting: That's the interesting question. Normally a bug tracker would basically be a SQL application. When you move it into a Git repo you lose that and now you have to think about how to represent all that relational data in your repository. It gets annoying. This is why for Fossil it's such a trivial thing to do: Fossil repositories _are_ relational and hoste…

> Normally a bug tracker would basically be a SQL application. When you move it into a Git repo you lose that and now you have to think about how to represent all that relational data in your repository. It gets annoying. > just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB Applications with SQL backends tackle the problem “how can we express our CRUD datast…

> The answer to “Why though?”

I addressed that in a different sub-thread. This one was about "why would you do it any other way?". My commentary about relational data in non-relational media was specifically about why do it any other way. There are great advantages to doing what TFA does -and I acknowledged that in a different sub-thread- but it's still interesting to consider what gets lost, and how to get some of it back.

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#94

I personally hate how all these platforms like GitHub, GitLab, BitBucket, etc slapped a centralized relational database to manage issues, comments, merge requests, etc next to a distributed de-centralized system like Git. I especially hate how they've integrated CI/CD into the Git platforms. I loathe the fact that Microsoft has tied their AI to their Git platform. I want my CI/CD to be agnostic. I want my AI to be ag…

The local first approach to dev tools and ecosystems does seem to be on the way out.

The pressures for this aren’t even explicitly corporate interest anymore, a lot of it is driven by non-software-experts who are kind of forced to participate in software dev (e.g. your friendly data science colleague who used to be, say, in material science or astrophysics), which is completely understandable. But more concerneing is the trend of actual software engineers who dislike consoles, terminal programs, and basically don’t believe much in understanding their tools.

You see this all the time with basic stuff from git UIs to kubernetes in IDEs. Productivity isn’t really the issue, although it’s always mentioned as an excuse, there’s just a big appeal to reducing any/every cognitive load no matter what the practical cost is for losing understanding/fluency. To give people the benefit of the doubt though, maybe this pressure is ultimately still corporate though and it started with the call for “full stack” devs, continued with devops/platform engineering etc, where specialists are often actively discouraged. Laziness and a higher tolerance for ignoring details may be a necessary virtue if the market forces everyone to be a generalist.

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#95
post #71

Earlier quoted context omitted.

Maybe because it’s less useful than you think. Companies and large orgs won’t be using it because they like centralized and on the small side your competition is a bunch of TODO files, not a bug tracker.

Yes, I understand that Jira exists, thanks.

The question was who wants to use git-bug, not why jira exists.

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#96

This is really neat! I know Microsoft would never integrate this into github, but what about integrating this other less vendor-lockin-ey scm platforms like forgejo or gitlab? It might be a much better fit then retrofitting activity-pub (current efforts in this space). Imagine having repository issues seamlessly propagated and replicated across all your git mirrors.

git-bug is built to be portable - today, the way git-bug interacts with other platforms which do not support reading from its namespaces directly is through bridges.

right now, git-bug has built-in bridges for github, gitlab, and jira. i am working on the design for a more modular system in which bridges can be built by anybody and used as "plugins".

really, though, the better, long-term goal is to work with $PLATFORMS to have them update their issue tracker to use git-bug's issues (that is, read from and publish to the refs/bugs namespace using git-bug). there's a bit missing right now to make this easy, but it's something that's very much top of mind as i think about git-bug's future.

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#97

I use this to note potential issues in my copy of the Git project. For outright bugs though I report them to the project.

awesome to see a user in the wild! if you weren't aware, you can publish your git-bug issues to the project's issue tracker, assuming that it's on one of the supported bridges today (github, gitlab, jira).

the bridges exist within git-bug to support adoption of the tool and interop with existing platforms.

`git bug bridge pull` and `git bug bridge push` use the bridge's API, and don't attempt to pull from or push to the git remote.

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#98

Very cool project — love the offline-first, Git-native approach. One question: How do you handle conflict resolution when multiple users modify the same issue or thread concurrently across remotes? Is it purely Git's merge mechanics, or do you apply any domain-specific heuristics?

maintainer here. great question!

git-bug embeds a "lamport timestamp" [0] - that is, a logical clock, not a wall clock - in each operation (like the creation of a bug, or a comment, or an edit to a comment). this, combined with the data model [1] we use, allow activity to be recorded and replayed without ever encountering a merge conflict.

[0]: https://en.wikipedia.org/wiki/Lamport_timestamp

[1]: https://github.com/git-bug/git-bug/blob/master/doc/design/da...

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#99
post #73

This is so cool! Much more elaborated and closer to the real bug tracker than my own tiny project ( https://github.com/jhspetersson/git-task ) (oh, sorry for the shameless plug)

looks neat! if you're interested in working on this sort of technology, git-bug needs more maintainers! (i also personally wouldn't mind a rust port, and have poked at this in the past).

Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

#100
I love this idea and any tool that reduces context switching out of the terminal (e.g. devdocs, fabric, tldr)

1. It may push the design boundaries, but a basic full text index with sqlite would be doable with the web interface. go-doc CLI does the same with the web UI. all indexing is client-side . The bug corpus is very small so indexing should be fast and consistent.

2. Tagging bugs with the observed and resolved git commit ID. that would improve bisect, merge, release management and changelog publication.

Post reply on HN