8 ms·

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

312 points by stefankuehnel 1y ago

hungryhobbit 1y ago
While I like the idea of tool consolidation, bug trackers aren't just a tool for the engineers. At most companies I've worked at, the support team, designers, QA team, managers, etc. all use the bug tracker on a daily basis. It sounds like you can "bridge" to somehow show the tracker outside Engineering, but then you're having to do work around the consolidation, and I'd imagine the result won't be as nice as a full-featured tracker designed for everyone to use. But, I am curious to hear from someone who has actually used this thing.
- hungryhobbit 1y ago
  P.S. The GitHub readme for this project desperately needs a "Why?" (... would anyone use it, ie. what benefits does it offer vs. say Jira?)
  - jFriedensreich 1y ago
    I think this is made for an audience who find it obvious. "Why would you do it any other way" would be more interesting: There is a weird divide between git supported features on one hand and pull requests/ merge requests/ patch lists/ issues/ bug trackers etc. If everything was supported in git all these features would be interoperable between forges like github, bitbucket and gitea, forgejo. Not only interoperability but backups, tooling, distributed workflows and everything in between would work consistently and the same way. That said, I cannot count the times this concept was brought up and tried to make work but despite how much i love the idea in theory, i have yet to see a way it could work in practice. Some of the issues: - no universal agreement on exact schema, feature set and workflows, do the competing implementations break each other? if its not interoperable why even bother vs just using an external solution - how to handle issues not associated to one specific repo or to multiple repos, splitting repos etc. - how to not confuse devs seeing issue branches or wherever the actual data is stored in the repo - how to best make this usable to non devs The list goes on
    - cryptonector 1y ago
      > "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 hosted on an RDBMS (SQLite3 or PG). If you don't have a SQL then referential integrity is easy to break (e.g., issues that refer to others that don't know they're being referred to), and querying your issue database becomes a problem as it gets huge because Git doesn't really have an appropriate index for this. What one might do to alleviate the relational issues is to just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB. Then as long as there are no non-fast-forward pushes to the issues DB it's always easy to catch up and have a functional relational database.
      - Git-Master 1y ago
        Two corrections: 1. Fossil repositories are explicitly not relational, they are however stored in SQLite databases. The data model for everything SCM-relevant (that also includes all content like tickets, wiki, forum) is stored as artifacts in a blob table (+ delta), which references other artifacts by hash value, and that provides the referential integrity. That, and the code that handles it. There are relations (via auxiliary tables) to speed up queries, but these tables are transient, get updated by inserting new artifacts, and can be regenerated from the artifacts. (Users and their metadata, and configuration is not part of this scheme, so these tables might be viewed as relational tables. They are local-only; and not synced.) See https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details. 2. There are no other databases like PostgreSQL to choose from.
        cryptonector 1y ago
        I get that the auxiliary tables speed up queries, but the data is relational in nature on some level. I thought that Fossil did or at least aimed to support different SQL RDBMSes. Did that go away at some point?
  - cryptonector 1y ago
    It's obvious. It's also not original. There are multiple things like this already. Fossil was the first tool to put bug tracking in the repository. Idk which VCS/forge was the first to put wikis in the repository, but it might have been GitHub or Fossil. The point here is to be able to work with issues, PRs, and wikis offline just as one is now used to doing with code. And to use the same underlying content-addressed version control tooling for all those things.
    - freddie_mercury 1y ago
      > Fossil was the first tool to put bug tracking in the repository I'm pretty sure Aegis did it 15 years before Fossil.
  - tasuki 1y ago
    > what benefits does it offer vs. say Jira? Not being Jira is already a huge benefit. It says offline, local first. Isn't that nice?
- hosh 1y ago
  I think that is more useful for communities whose members don't have reliable, always-on networks, rather than workflows within companies.
- bluGill 1y ago
  All those users are why bug trackers are annoying. I don't care about those fields "those other people" are demanding, why do I need to fill them out. Mean while they don't care about the fields that are critical for me and don't want to fill them out.
  - baq 1y ago
    Every job has a part people don't like that's necessary. The company you work for pays you money to fill the fields out, you fill them out, you get paid.
    - XorNot 1y ago
      That's why I do it. That doesn't explain why they even need to be there. For example every project code drop down has this experience: my manager tells me what project code to put everything against, then I always pick the same option. Sometimes I've not been granted access to that option and waste a bunch of time getting that turned on. At no point was any part of this necessary, because I neither defined the ticket, or could select the project code for myself, but we're all engaged in an elaborate game pretending I had agency over it.
      - AndrewDucker 1y ago
        If you're working somewhere competent then every budget code is an indicator that a manager with a budget has said that they are willing to pay for this piece of work to be done. It may even automatically keep track of how much of their budget was spent on you doing the work.
    - account42 1y ago
      Or you could show initiative and improve inefficient processes instead of blindly following "how things are done".
  - pixl97 1y ago
    There's no I in team... Or to put it another way, those other 'useless' fields that take minutes may save the company hours of time in places that you don't see.
- devrandoom 1y ago
  This is a bug tracker. What you are describing is much closer to a project management tool, just to make the difference clear.
  - whateveracct 1y ago
    To some people, engineers without project management doesn't make any sense.
  - dcrazy 1y ago
    Those should be tightly integrated, if not the same tool.
    - nine_k 1y ago
      It depends on who manages the project. In an open-source project, those will likely also be engineering types, not non-technical managers. It's hard to make a product that's all things to all people, and it's wise to make a product that has a well-understood, if more narrow, audience.
- chungy 1y ago
  Fossil[0] has bug tracking as a standard feature, and through the HTTP role-based authentication, you are able to set up users with different privileges; for instance, being able to read and write the bug tracker without the ability to push new code. [0]: https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
  - ndegruchy 1y ago
    +1 for this. I love having a self-contained, syncable GitHub-lite. It uses SQLite for the format, too, which makes it easy to discover the internals. It just needs some more 'modern' themes
    - debugnik 1y ago
      > It uses SQLite for the format My chance at sharing Fossil is not Relational. The two times it's been submitted to HN it didn't gain votes. https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...
      - ndegruchy 1y ago
        Thanks for that. I kind of wondered how SQLite was relevant to SCM, but I hadn't really bothered to investigate it. Still, having it in a format that can be browsed and reasoned about is handy. Not that Git is any worse in this regard. Plus, the only thing I need to do to transfer it to a new disk or network location is to move the `.fossil` file, since everything is nicely self-contained.
- sudoforge 1y ago
  hey! maintainer here. git-bug has a web ui that you can run on your git server, for example, that can be accessed through a browser. it's fairly limited in functionality right now (create, comment on, and manage issues), but one of my goals is to refactor it to improve coverage of the existing features, and to add support for things like: - authenticated access - unauthenticated/anonymous access (e.g. a public, external contributor/user) - issue privacy levels - sprints, projects, report generation
- layer8 1y ago
  Improved user interfaces can always be added on top of the CLI/library functionality, and that’s the more flexible approach. Everyone can use and/or build their favorite UI, like people do with Git itself. The monolithic web-first (often web-only) systems are a bit of a modern bane, you’re stuck with whatever user interface the one company/maintainer deems appropriate.
  - baq 1y ago
    It’s expensive to maintain more front ends than you absolutely require. Web+mobile is one too many already.
- eikenberry 1y ago
  Maybe the tool isn't intended for use in commercial environments. There is plenty of work done outside a those environments where this tool might be a better fit. E.g. most free software projects don't have all those other teams interacting with the bug trackers. To put it another way, this seems to fill a similar niche as Github's bug tracker and not Jira.
- crabbone 1y ago
  Designers, QA, support and managers are typically already using a VCS, and usually it's Git. And if they don't, this is as good as ever a chance to start. From QA perspective, which is the one the closest to me: I wanted such a tool for many years, and even though I haven't tried this specific one, I endorse the idea with both of my hands. In the context of QA, it's always a problem to coordinate between test development, feature development, feature description, and tracking the work progress. All bug trackers I used to date are awful at it. This has a potential to solve at least part of the problem by being physically connected to the work done by either development or QA, or, ideally, both. The holy grail here is the ability to determine what tests to run in response to a commit without making it too much of a burden on the committer. Tests can easily be the most expensive ongoing activity a development company may undertake. In this context, being able to avoid running useless but expensive tests is very desirable.
WD-42 1y ago
This is incredibly cool. I love seeing local first software starting to make a comeback. Github is becoming painful to use, even on a fast connection.
- binary132 1y ago
  The fact that nearly all of our source code is not only hosted on proprietary platforms that can (and do) delete it any time they like, but is ALSO integrated with many of our build systems so that it’s not trivially relocatable blows my mind every time I think about it.
  - kgeist 1y ago
    If you want to be serious about this, use a self-hosted CI/CD server such as TeamCity, and then mirror all dependencies on a local git server (Go supports GOPROXY variable, but you can also probably fiddle with local DNS and self-signed certs, so that any mention of github.com forwarded you to the local server). This way, it's more controllable: if github.com is down or some repo is deleted, the CI/CD server won't even notice it.
    - binary132 1y ago
      I know there are workarounds, I’m talking about the general principle or the situation at large.
pacifika 1y ago
Might be interesting as a personal cross project todo tracker?
tiffanyh 1y ago
Interesting that GPL3 was selected for this, while Git itself is GPL2 (these are incompatible licenses)
- chungy 1y ago
  It'd only really matter if git-bug were to become part of the core Git features. Perhaps one or the other could relicense if that became a desirable outcome. I have doubt it'll happen. GitHub/GitLab culture is pretty strong, few seem interested in having distributed project management features.
IshKebab 1y ago
This really seems like an odd thing to make distributed. Do I now have to resolve conflicts in bug conversations? Am I going to find replies magically appearing before mine? The README doesn't even acknowledge that these difficulties might exist. This sounds like it adds a ton of potential problems and solves some very minor ones: * You can work offline. Great, but 90% of bug tracking is sending messages to other people so that's not particularly useful. * You aren't tied to GitHub Issues or whatever. I guess that's good. Seems pretty marginal though.
- riedel 1y ago
  I think there is multiple cases where repos are mirrored between Codeberg, GitHub and internal and public instances of Gitlab. People want to open issues where they are and they can get accounts. Also I had to migrate issues from one repo to the other. Having wikis moved to git repos is a big advantage over trac and redmine (we just recently moved old projects and it is a pain each time). So I highly welcome anyone who moves issue tracking to git as well.
- sudoforge 1y ago
  hey, maintainer here! > Do I now have to resolve conflicts in bug conversations? > Am I going to find replies magically appearing before mine? actually, no! git-bug objects embed a lamport timestamp [0] to handle time-based ordering, and actions like comment posting and editing are tracked as "operations", applied in order, and you will never have to deal with a merge conflict. the data model documentation [1] provides deeper insight into how we handle time, describe why you'll never see a merge conflict, and more. through this post, i've gathered that many people would prefer this sort of documentation be made more visible in the README (instead of "buried" under //doc). the README is probably a bit too high level for a more technical audience, but i appreciate your feedback here, and will take it into consideration as the README is refactored. [0]: https://en.wikipedia.org/wiki/Lamport_timestamp https://en.wikipedia.org/wiki/Lamport_timestamp [1]: https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...
  - 1y ago
rzwitserloot 1y ago
I've been yelling 'omg why doesnt someone build a ticketing system on the basis of git, having a separate 'root' (no-parent git commit that is at the bottom of a git tree; technically a git repo can have more than one), with most of the conversation happening in git commit form' - for YEARS. This is wildly exciting.
- wahern 1y ago
  FWIW, this project made its first release in 2018. =) It's been posted to HN several times, though under its previous project URL, https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug (see https://news.ycombinator.com/from?site=github.com/michaelmure https://news.ycombinator.com/from?site=github.com/michaelmur...)
- sudoforge 1y ago
  you aren't alone! linus thinks we need this, too: https://youtu.be/sCr_gb8rdEI?t=1533 https://youtu.be/sCr_gb8rdEI?t=1533
- yogsototh 1y ago
  I had the same idea for a talk a long time ago the result is https://git.esy.fun/yogsototh/gpm https://git.esy.fun/yogsototh/gpm I never used it seriously, but the concepts are easy enough to grasp. Have a separate dedicated branch that contains all the metadata of your project. Like issues, todo-list, review comments, etc... Hopefully, something decentralised like this could become more popular maybe.
stratosgear 1y ago
Docs seem to miss instructions on how you add a bug! Did I miss it?
- dannyfritz07 1y ago
  https://github.com/git-bug/git-bug/blob/master/doc/md/git-bug_bug_new.md https://github.com/git-bug/git-bug/blob/master/doc/md/git-bu...
binary132 1y ago
It’s very weird seeing the coping / seething about a useful tool like this even in HN comments. People have really drunk the proverbial kool-aid / joined the dark side.
- haukilup 1y ago
  > It’s very weird seeing the coping / seething about a useful tool like this even in HN comments. People have really drunk the proverbial kool-aid / joined the dark side. It’s unclear to me what you mean.
- baq 1y ago
  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.
  - binary132 1y ago
    Yes, I understand that Jira exists, thanks.
    - baq 1y ago
      The question was who wants to use git-bug, not why jira exists.
layer8 1y ago
Some screenshots would be nice. I found this one [0] of the TUI from 2018, but not much else. [0] https://github.com/git-bug/git-bug/releases/tag/0.4.0 https://github.com/git-bug/git-bug/releases/tag/0.4.0
- sudoforge 1y ago
  maintainer here - this is great feedback! i recently rewrote the README because i felt like its previous iteration was a bit _too_ dense. i may have gone a bit overboard on moving things :) FWIW, the screenshots you're looking for currently live in: https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/doc/usage/interfaces.md https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...
  - bognition 1y ago
    honestly cleaning up the Readme and documentation would go a very long way, right now all the information feels fragmented behind all of the little pages. I clicked into the documentation and clicked the first link presented to me on each page and 5 clicks or so in I was on the command line docs but I hadn't seen anything that gave me a high level overview of what git-bug is, what it does, why I want to use it, etc... I understand that documentation can be hard and you need docs for newbies and long time users, but as a newbie I cannot for the life of me figure out what this is.
  - binary132 1y ago
    This would be amazing as a Magit module for Emacs. I don’t relish the idea of using it in a terminal alongside Emacs while using Git from inside Emacs. Is there a lower-level interface that Magit could provide a porcelain for, maybe?
    - sudoforge 1y ago
      i have no understanding, beyond that of a lexical nature, what a "magit module" is. i'm a (neo)vim user, and heavy terminal junkie, and if i wanted to build a vim plugin for git-bug, that plugin would likely be shelling out to the command line (as git-bug doesn't expose an independent API today -- it's only started when you start the web ui). is a "magit module" roughly synonymous with a vim plugin? if so, then would shelling out to the CLI work?
dannymi 1y ago
There's also https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue which has much fewer dependencies.
johanbcn 1y ago
Funny. Some days ago, on the Firefox mover to github topic, people were wondering if issue trackers should also be distributed. Seems an interesting idea.
mhh__ 1y ago
Love this kind of thing. Particularly in the age of AI being cheap and even on device there are even more reasons to have issues be near the code for easy access. Similarly things like automatically promoting bugs into the test suite as SHOULD FAIL and so on
MichaelBosworth 1y ago
Excited to try this. I like the look of that TUI.
deleted 1y ago
[deleted]
omneity 1y ago
This looks cool and has the opportunity to replace my old and trusted todo.txt, but I couldn’t find how to create or resolve bugs. The CLI has features related to syncing but nothing about this, or did I miss something?
- azthecx 1y ago
  If you're looking at the CLI there are specific man pages for it. You can find creation here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgit-bug_bug_new.md https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi... And status update here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgit-bug_bug_status.md https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi...
  - omneity 1y ago
    Yeah it was right in front of me and I missed it. Thanks a bunch!
AceJohnny2 1y ago
I love seeing these projects make use of the wide-open namespace/references that git provides (outside of the basic `refs/heads` for git branches and `refs/tags` for tags). It looks like they store the data in the `bugs` namespace [1] (so refs/bugs/foo). Other projects also make use of alternate namespaces. The oft-forgotten built-in "git notes" puts stuff in the `refs/notes/` namespace (specifically in `refs/notes/commits`). Gerrit uses the virtual `refs/for/` namespace for receiving commits for review, stores project config in `refs/meta/config`, and stores User data in `refs/users/` in a special repo [2]. I'm sure others do interesting things. Alternate uses of git's DAG model are fascinating. [1] https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/entities/bug/bug.go#L26 https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9... [2] https://gerrit-review.googlesource.com/Documentation/config-accounts.html https://gerrit-review.googlesource.com/Documentation/config-...
- michaelmure 1y ago
  Yes, this really meant to be some sort of framework for storing entities in git, handle the conflicts, and let you buld easily your own tool (or add more features to git-bug). See also https://github.com/git-bug/git-bug/blob/master/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/master/doc/design/da... and https://github.com/git-bug/git-bug/blob/master/entity/dag/example_test.go https://github.com/git-bug/git-bug/blob/master/entity/dag/ex... I'd love to see this used in the wild for other use cases.
- farhanhubble 1y ago
  Wow!So this can be used for full blown project management too.
  - alchemist1e9 1y ago
    Could you expand on how you see that working? combining these extensions is what I’m guessing but I’d be super interested in hearing how it might work. If all information for an asynchronous development process could be stored into git and distributed by it, this would be a very good idea for many projects.
alasr 1y ago
Git Bug screenshots: - TUI recording (GIF): https://github.com/git-bug/git-bug/blob/master/doc/assets/tui-recording.gif https://github.com/git-bug/git-bug/blob/master/doc/assets/tu... - Web comments (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/web-screenshot-comments.png https://github.com/git-bug/git-bug/blob/master/doc/assets/we... - Web feed (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/web-screenshot-feed.png https://github.com/git-bug/git-bug/blob/master/doc/assets/we...
jhspt 1y ago
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 https://github.com/jhspetersson/git-task) (oh, sorry for the shameless plug)
- sudoforge 1y ago
  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).
chrishill89 1y ago
I use this to note potential issues in my copy of the Git project. For outright bugs though I report them to the project.
- sudoforge 1y ago
  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.
  - chrishill89 1y ago
    Thanks. I can’t push it to the issue tracker since they don’t have one. Bug reports go to the mailing list.
    - sudoforge 1y ago
      hrm... what's your current workflow like? if there's anything you think git-bug could be doing to make that workflow easier, would you mind hopping in our matrix channel [1], or opening an issue [2]? [1]: https://matrix.to/#/#git-bug:matrix.org https://matrix.to/#/#git-bug:matrix.org [2]: https://github.com/git-bug/git-bug/issues https://github.com/git-bug/git-bug/issues
      - chrishill89 1y ago
        I create issues for myself. I sometimes create branches with informal issue keys like `<three letters>-<incrementing number>`. I use `git bug webui` to type edit issues. That’s it. All I would like as a nice-to-have is support for making those issue keys that I use automatic. For me it’s all local to me so it doesn’t need to be globally unique. But those N-letter prefix does make collision less likely on a single project. I’ve mentioned it here: https://github.com/git-bug/git-bug/issues/75#issuecomment-1925240469 https://github.com/git-bug/git-bug/issues/75#issuecomment-19...
badmonster 1y ago
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?
- sudoforge 1y ago
  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 https://en.wikipedia.org/wiki/Lamport_timestamp [1]: https://github.com/git-bug/git-bug/blob/master/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/master/doc/design/da...
silverliver 1y ago
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.
- sudoforge 1y ago
  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.
stephenr 1y ago
It's a little disappointing that BugsEverywhere/BE (https://github.com/aaiyer/bugseverywhere https://github.com/aaiyer/bugseverywhere) never gained popularity. I appreciate that tools like Git Bug are not tied to a single repo host but they are tied inherently to a single VCS (git). BE was not reliant on a specific VCS, and it's a *really* simple format on-disk too.
- michaelmure 1y ago
  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/repo.go https://github.com/git-bug/git-bug/blob/master/repository/re...
ThinkBeat 1y ago
It would be nice to see some screenshots of the tool. But it could be me not looking in the right place. I tried to find it among the documentation too.
gitroom 1y ago
[dead]
ericfrederich 1y ago
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.
- photonthug 1y ago
  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.
- spit2wind 1y ago
  Have you tried Fossil? https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
jiehong 1y ago
Is there anybody using a sub directory in the fit repo with one markdown per ticket?
tonymet 1y ago
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.

312 points by stefankuehnel 1y ago

While I like the idea of tool consolidation, bug trackers aren't just a tool for the engineers. At most companies I've worked at, the support team, designers, QA team, managers, etc. all use the bug tracker on a daily basis. It sounds like you can "bridge" to somehow show the tracker outside Engineering, but then you're having to do work around the consolidation, and I'd imagine the result won't be as nice as a full-featured tracker designed for everyone to use. But, I am curious to hear from someone who has actually used this thing.

hungryhobbit 1y ago
P.S. The GitHub readme for this project desperately needs a "Why?" (... would anyone use it, ie. what benefits does it offer vs. say Jira?)
- jFriedensreich 1y ago
  I think this is made for an audience who find it obvious. "Why would you do it any other way" would be more interesting: There is a weird divide between git supported features on one hand and pull requests/ merge requests/ patch lists/ issues/ bug trackers etc. If everything was supported in git all these features would be interoperable between forges like github, bitbucket and gitea, forgejo. Not only interoperability but backups, tooling, distributed workflows and everything in between would work consistently and the same way. That said, I cannot count the times this concept was brought up and tried to make work but despite how much i love the idea in theory, i have yet to see a way it could work in practice. Some of the issues: - no universal agreement on exact schema, feature set and workflows, do the competing implementations break each other? if its not interoperable why even bother vs just using an external solution - how to handle issues not associated to one specific repo or to multiple repos, splitting repos etc. - how to not confuse devs seeing issue branches or wherever the actual data is stored in the repo - how to best make this usable to non devs The list goes on
  - cryptonector 1y ago
    > "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 hosted on an RDBMS (SQLite3 or PG). If you don't have a SQL then referential integrity is easy to break (e.g., issues that refer to others that don't know they're being referred to), and querying your issue database becomes a problem as it gets huge because Git doesn't really have an appropriate index for this. What one might do to alleviate the relational issues is to just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB. Then as long as there are no non-fast-forward pushes to the issues DB it's always easy to catch up and have a functional relational database.
    - Git-Master 1y ago
      Two corrections: 1. Fossil repositories are explicitly not relational, they are however stored in SQLite databases. The data model for everything SCM-relevant (that also includes all content like tickets, wiki, forum) is stored as artifacts in a blob table (+ delta), which references other artifacts by hash value, and that provides the referential integrity. That, and the code that handles it. There are relations (via auxiliary tables) to speed up queries, but these tables are transient, get updated by inserting new artifacts, and can be regenerated from the artifacts. (Users and their metadata, and configuration is not part of this scheme, so these tables might be viewed as relational tables. They are local-only; and not synced.) See https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details. 2. There are no other databases like PostgreSQL to choose from.
      - cryptonector 1y ago
        I get that the auxiliary tables speed up queries, but the data is relational in nature on some level. I thought that Fossil did or at least aimed to support different SQL RDBMSes. Did that go away at some point?
- cryptonector 1y ago
  It's obvious. It's also not original. There are multiple things like this already. Fossil was the first tool to put bug tracking in the repository. Idk which VCS/forge was the first to put wikis in the repository, but it might have been GitHub or Fossil. The point here is to be able to work with issues, PRs, and wikis offline just as one is now used to doing with code. And to use the same underlying content-addressed version control tooling for all those things.
  - freddie_mercury 1y ago
    > Fossil was the first tool to put bug tracking in the repository I'm pretty sure Aegis did it 15 years before Fossil.
- tasuki 1y ago
  > what benefits does it offer vs. say Jira? Not being Jira is already a huge benefit. It says offline, local first. Isn't that nice?
hosh 1y ago
I think that is more useful for communities whose members don't have reliable, always-on networks, rather than workflows within companies.
bluGill 1y ago
All those users are why bug trackers are annoying. I don't care about those fields "those other people" are demanding, why do I need to fill them out. Mean while they don't care about the fields that are critical for me and don't want to fill them out.
- baq 1y ago
  Every job has a part people don't like that's necessary. The company you work for pays you money to fill the fields out, you fill them out, you get paid.
  - XorNot 1y ago
    That's why I do it. That doesn't explain why they even need to be there. For example every project code drop down has this experience: my manager tells me what project code to put everything against, then I always pick the same option. Sometimes I've not been granted access to that option and waste a bunch of time getting that turned on. At no point was any part of this necessary, because I neither defined the ticket, or could select the project code for myself, but we're all engaged in an elaborate game pretending I had agency over it.
    - AndrewDucker 1y ago
      If you're working somewhere competent then every budget code is an indicator that a manager with a budget has said that they are willing to pay for this piece of work to be done. It may even automatically keep track of how much of their budget was spent on you doing the work.
  - account42 1y ago
    Or you could show initiative and improve inefficient processes instead of blindly following "how things are done".
- pixl97 1y ago
  There's no I in team... Or to put it another way, those other 'useless' fields that take minutes may save the company hours of time in places that you don't see.
devrandoom 1y ago
This is a bug tracker. What you are describing is much closer to a project management tool, just to make the difference clear.
- whateveracct 1y ago
  To some people, engineers without project management doesn't make any sense.
- dcrazy 1y ago
  Those should be tightly integrated, if not the same tool.
  - nine_k 1y ago
    It depends on who manages the project. In an open-source project, those will likely also be engineering types, not non-technical managers. It's hard to make a product that's all things to all people, and it's wise to make a product that has a well-understood, if more narrow, audience.
chungy 1y ago
Fossil[0] has bug tracking as a standard feature, and through the HTTP role-based authentication, you are able to set up users with different privileges; for instance, being able to read and write the bug tracker without the ability to push new code. [0]: https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
- ndegruchy 1y ago
  +1 for this. I love having a self-contained, syncable GitHub-lite. It uses SQLite for the format, too, which makes it easy to discover the internals. It just needs some more 'modern' themes
  - debugnik 1y ago
    > It uses SQLite for the format My chance at sharing Fossil is not Relational. The two times it's been submitted to HN it didn't gain votes. https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...
    - ndegruchy 1y ago
      Thanks for that. I kind of wondered how SQLite was relevant to SCM, but I hadn't really bothered to investigate it. Still, having it in a format that can be browsed and reasoned about is handy. Not that Git is any worse in this regard. Plus, the only thing I need to do to transfer it to a new disk or network location is to move the `.fossil` file, since everything is nicely self-contained.
sudoforge 1y ago
hey! maintainer here. git-bug has a web ui that you can run on your git server, for example, that can be accessed through a browser. it's fairly limited in functionality right now (create, comment on, and manage issues), but one of my goals is to refactor it to improve coverage of the existing features, and to add support for things like: - authenticated access - unauthenticated/anonymous access (e.g. a public, external contributor/user) - issue privacy levels - sprints, projects, report generation
layer8 1y ago
Improved user interfaces can always be added on top of the CLI/library functionality, and that’s the more flexible approach. Everyone can use and/or build their favorite UI, like people do with Git itself. The monolithic web-first (often web-only) systems are a bit of a modern bane, you’re stuck with whatever user interface the one company/maintainer deems appropriate.
- baq 1y ago
  It’s expensive to maintain more front ends than you absolutely require. Web+mobile is one too many already.
eikenberry 1y ago
Maybe the tool isn't intended for use in commercial environments. There is plenty of work done outside a those environments where this tool might be a better fit. E.g. most free software projects don't have all those other teams interacting with the bug trackers. To put it another way, this seems to fill a similar niche as Github's bug tracker and not Jira.
crabbone 1y ago
Designers, QA, support and managers are typically already using a VCS, and usually it's Git. And if they don't, this is as good as ever a chance to start. From QA perspective, which is the one the closest to me: I wanted such a tool for many years, and even though I haven't tried this specific one, I endorse the idea with both of my hands. In the context of QA, it's always a problem to coordinate between test development, feature development, feature description, and tracking the work progress. All bug trackers I used to date are awful at it. This has a potential to solve at least part of the problem by being physically connected to the work done by either development or QA, or, ideally, both. The holy grail here is the ability to determine what tests to run in response to a commit without making it too much of a burden on the committer. Tests can easily be the most expensive ongoing activity a development company may undertake. In this context, being able to avoid running useless but expensive tests is very desirable.

WD-42 1y ago

This is incredibly cool. I love seeing local first software starting to make a comeback. Github is becoming painful to use, even on a fast connection.

binary132 1y ago
The fact that nearly all of our source code is not only hosted on proprietary platforms that can (and do) delete it any time they like, but is ALSO integrated with many of our build systems so that it’s not trivially relocatable blows my mind every time I think about it.
- kgeist 1y ago
  If you want to be serious about this, use a self-hosted CI/CD server such as TeamCity, and then mirror all dependencies on a local git server (Go supports GOPROXY variable, but you can also probably fiddle with local DNS and self-signed certs, so that any mention of github.com forwarded you to the local server). This way, it's more controllable: if github.com is down or some repo is deleted, the CI/CD server won't even notice it.
  - binary132 1y ago
    I know there are workarounds, I’m talking about the general principle or the situation at large.

pacifika 1y ago

Might be interesting as a personal cross project todo tracker?

tiffanyh 1y ago

Interesting that GPL3 was selected for this, while Git itself is GPL2 (these are incompatible licenses)

chungy 1y ago
It'd only really matter if git-bug were to become part of the core Git features. Perhaps one or the other could relicense if that became a desirable outcome. I have doubt it'll happen. GitHub/GitLab culture is pretty strong, few seem interested in having distributed project management features.

IshKebab 1y ago

This really seems like an odd thing to make distributed. Do I now have to resolve conflicts in bug conversations? Am I going to find replies magically appearing before mine? The README doesn't even acknowledge that these difficulties might exist. This sounds like it adds a ton of potential problems and solves some very minor ones: * You can work offline. Great, but 90% of bug tracking is sending messages to other people so that's not particularly useful. * You aren't tied to GitHub Issues or whatever. I guess that's good. Seems pretty marginal though.

riedel 1y ago
I think there is multiple cases where repos are mirrored between Codeberg, GitHub and internal and public instances of Gitlab. People want to open issues where they are and they can get accounts. Also I had to migrate issues from one repo to the other. Having wikis moved to git repos is a big advantage over trac and redmine (we just recently moved old projects and it is a pain each time). So I highly welcome anyone who moves issue tracking to git as well.
sudoforge 1y ago
hey, maintainer here! > Do I now have to resolve conflicts in bug conversations? > Am I going to find replies magically appearing before mine? actually, no! git-bug objects embed a lamport timestamp [0] to handle time-based ordering, and actions like comment posting and editing are tracked as "operations", applied in order, and you will never have to deal with a merge conflict. the data model documentation [1] provides deeper insight into how we handle time, describe why you'll never see a merge conflict, and more. through this post, i've gathered that many people would prefer this sort of documentation be made more visible in the README (instead of "buried" under //doc). the README is probably a bit too high level for a more technical audience, but i appreciate your feedback here, and will take it into consideration as the README is refactored. [0]: https://en.wikipedia.org/wiki/Lamport_timestamp https://en.wikipedia.org/wiki/Lamport_timestamp [1]: https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...
- 1y ago

rzwitserloot 1y ago

I've been yelling 'omg why doesnt someone build a ticketing system on the basis of git, having a separate 'root' (no-parent git commit that is at the bottom of a git tree; technically a git repo can have more than one), with most of the conversation happening in git commit form' - for YEARS. This is wildly exciting.

wahern 1y ago
FWIW, this project made its first release in 2018. =) It's been posted to HN several times, though under its previous project URL, https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug (see https://news.ycombinator.com/from?site=github.com/michaelmure https://news.ycombinator.com/from?site=github.com/michaelmur...)
sudoforge 1y ago
you aren't alone! linus thinks we need this, too: https://youtu.be/sCr_gb8rdEI?t=1533 https://youtu.be/sCr_gb8rdEI?t=1533
yogsototh 1y ago
I had the same idea for a talk a long time ago the result is https://git.esy.fun/yogsototh/gpm https://git.esy.fun/yogsototh/gpm I never used it seriously, but the concepts are easy enough to grasp. Have a separate dedicated branch that contains all the metadata of your project. Like issues, todo-list, review comments, etc... Hopefully, something decentralised like this could become more popular maybe.

stratosgear 1y ago

Docs seem to miss instructions on how you add a bug! Did I miss it?

dannyfritz07 1y ago
https://github.com/git-bug/git-bug/blob/master/doc/md/git-bug_bug_new.md https://github.com/git-bug/git-bug/blob/master/doc/md/git-bu...

binary132 1y ago

It’s very weird seeing the coping / seething about a useful tool like this even in HN comments. People have really drunk the proverbial kool-aid / joined the dark side.

haukilup 1y ago
> It’s very weird seeing the coping / seething about a useful tool like this even in HN comments. People have really drunk the proverbial kool-aid / joined the dark side. It’s unclear to me what you mean.
baq 1y ago
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.
- binary132 1y ago
  Yes, I understand that Jira exists, thanks.
  - baq 1y ago
    The question was who wants to use git-bug, not why jira exists.

layer8 1y ago

Some screenshots would be nice. I found this one [0] of the TUI from 2018, but not much else. [0] https://github.com/git-bug/git-bug/releases/tag/0.4.0 https://github.com/git-bug/git-bug/releases/tag/0.4.0

sudoforge 1y ago
maintainer here - this is great feedback! i recently rewrote the README because i felt like its previous iteration was a bit _too_ dense. i may have gone a bit overboard on moving things :) FWIW, the screenshots you're looking for currently live in: https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/doc/usage/interfaces.md https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...
- bognition 1y ago
  honestly cleaning up the Readme and documentation would go a very long way, right now all the information feels fragmented behind all of the little pages. I clicked into the documentation and clicked the first link presented to me on each page and 5 clicks or so in I was on the command line docs but I hadn't seen anything that gave me a high level overview of what git-bug is, what it does, why I want to use it, etc... I understand that documentation can be hard and you need docs for newbies and long time users, but as a newbie I cannot for the life of me figure out what this is.
- binary132 1y ago
  This would be amazing as a Magit module for Emacs. I don’t relish the idea of using it in a terminal alongside Emacs while using Git from inside Emacs. Is there a lower-level interface that Magit could provide a porcelain for, maybe?
  - sudoforge 1y ago
    i have no understanding, beyond that of a lexical nature, what a "magit module" is. i'm a (neo)vim user, and heavy terminal junkie, and if i wanted to build a vim plugin for git-bug, that plugin would likely be shelling out to the command line (as git-bug doesn't expose an independent API today -- it's only started when you start the web ui). is a "magit module" roughly synonymous with a vim plugin? if so, then would shelling out to the CLI work?

dannymi 1y ago

There's also https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue which has much fewer dependencies.

johanbcn 1y ago

Funny. Some days ago, on the Firefox mover to github topic, people were wondering if issue trackers should also be distributed. Seems an interesting idea.

mhh__ 1y ago

Love this kind of thing. Particularly in the age of AI being cheap and even on device there are even more reasons to have issues be near the code for easy access. Similarly things like automatically promoting bugs into the test suite as SHOULD FAIL and so on

MichaelBosworth 1y ago

Excited to try this. I like the look of that TUI.

deleted 1y ago

[deleted]

omneity 1y ago

This looks cool and has the opportunity to replace my old and trusted todo.txt, but I couldn’t find how to create or resolve bugs. The CLI has features related to syncing but nothing about this, or did I miss something?

azthecx 1y ago
If you're looking at the CLI there are specific man pages for it. You can find creation here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgit-bug_bug_new.md https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi... And status update here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgit-bug_bug_status.md https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi...
- omneity 1y ago
  Yeah it was right in front of me and I missed it. Thanks a bunch!

AceJohnny2 1y ago

I love seeing these projects make use of the wide-open namespace/references that git provides (outside of the basic `refs/heads` for git branches and `refs/tags` for tags). It looks like they store the data in the `bugs` namespace [1] (so refs/bugs/foo). Other projects also make use of alternate namespaces. The oft-forgotten built-in "git notes" puts stuff in the `refs/notes/` namespace (specifically in `refs/notes/commits`). Gerrit uses the virtual `refs/for/` namespace for receiving commits for review, stores project config in `refs/meta/config`, and stores User data in `refs/users/` in a special repo [2]. I'm sure others do interesting things. Alternate uses of git's DAG model are fascinating. [1] https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/entities/bug/bug.go#L26 https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9... [2] https://gerrit-review.googlesource.com/Documentation/config-accounts.html https://gerrit-review.googlesource.com/Documentation/config-...

michaelmure 1y ago
Yes, this really meant to be some sort of framework for storing entities in git, handle the conflicts, and let you buld easily your own tool (or add more features to git-bug). See also https://github.com/git-bug/git-bug/blob/master/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/master/doc/design/da... and https://github.com/git-bug/git-bug/blob/master/entity/dag/example_test.go https://github.com/git-bug/git-bug/blob/master/entity/dag/ex... I'd love to see this used in the wild for other use cases.
farhanhubble 1y ago
Wow!So this can be used for full blown project management too.
- alchemist1e9 1y ago
  Could you expand on how you see that working? combining these extensions is what I’m guessing but I’d be super interested in hearing how it might work. If all information for an asynchronous development process could be stored into git and distributed by it, this would be a very good idea for many projects.

alasr 1y ago

Git Bug screenshots: - TUI recording (GIF): https://github.com/git-bug/git-bug/blob/master/doc/assets/tui-recording.gif https://github.com/git-bug/git-bug/blob/master/doc/assets/tu... - Web comments (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/web-screenshot-comments.png https://github.com/git-bug/git-bug/blob/master/doc/assets/we... - Web feed (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/web-screenshot-feed.png https://github.com/git-bug/git-bug/blob/master/doc/assets/we...

jhspt 1y ago

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 https://github.com/jhspetersson/git-task) (oh, sorry for the shameless plug)

sudoforge 1y ago
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).

chrishill89 1y ago

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

sudoforge 1y ago
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.
- chrishill89 1y ago
  Thanks. I can’t push it to the issue tracker since they don’t have one. Bug reports go to the mailing list.
  - sudoforge 1y ago
    hrm... what's your current workflow like? if there's anything you think git-bug could be doing to make that workflow easier, would you mind hopping in our matrix channel [1], or opening an issue [2]? [1]: https://matrix.to/#/#git-bug:matrix.org https://matrix.to/#/#git-bug:matrix.org [2]: https://github.com/git-bug/git-bug/issues https://github.com/git-bug/git-bug/issues
    - chrishill89 1y ago
      I create issues for myself. I sometimes create branches with informal issue keys like `<three letters>-<incrementing number>`. I use `git bug webui` to type edit issues. That’s it. All I would like as a nice-to-have is support for making those issue keys that I use automatic. For me it’s all local to me so it doesn’t need to be globally unique. But those N-letter prefix does make collision less likely on a single project. I’ve mentioned it here: https://github.com/git-bug/git-bug/issues/75#issuecomment-1925240469 https://github.com/git-bug/git-bug/issues/75#issuecomment-19...

badmonster 1y ago

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?

sudoforge 1y ago
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 https://en.wikipedia.org/wiki/Lamport_timestamp [1]: https://github.com/git-bug/git-bug/blob/master/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/master/doc/design/da...

silverliver 1y ago

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.

sudoforge 1y ago
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.

stephenr 1y ago

It's a little disappointing that BugsEverywhere/BE (https://github.com/aaiyer/bugseverywhere https://github.com/aaiyer/bugseverywhere) never gained popularity. I appreciate that tools like Git Bug are not tied to a single repo host but they are tied inherently to a single VCS (git). BE was not reliant on a specific VCS, and it's a *really* simple format on-disk too.

michaelmure 1y ago
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/repo.go https://github.com/git-bug/git-bug/blob/master/repository/re...

ThinkBeat 1y ago

It would be nice to see some screenshots of the tool. But it could be me not looking in the right place. I tried to find it among the documentation too.

gitroom 1y ago

[dead]

ericfrederich 1y ago

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.

photonthug 1y ago
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.
spit2wind 1y ago
Have you tried Fossil? https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki

jiehong 1y ago

Is there anybody using a sub directory in the fit repo with one markdown per ticket?

tonymet 1y ago

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.