[HN Gopher] Git Bug: Distributed, Offline-First Bug Tracker Embe...
___________________________________________________________________
Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git,
with Bridges
Author : stefankuehnel
Score : 136 points
Date : 2025-05-13 11:07 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hungryhobbit wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > "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 wrote:
| 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-rela... and 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 wrote:
| 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?
| jFriedensreich wrote:
| I don't think that is the main issue. Its not THAT hard
| to build a secondary sqlite index for data stored in git
| and keep in in sync especially because the data is
| already versioned and can be incrementally updated.
| cryptonector wrote:
| 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.
| hosh wrote:
| I think that is more useful for communities whose members don't
| have reliable, always-on networks, rather than workflows within
| companies.
| bluGill wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pixl97 wrote:
| 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 wrote:
| This is a bug tracker. What you are describing is much closer
| to a project management tool, just to make the difference
| clear.
| whateveracct wrote:
| To some people, engineers without project management doesn't
| make any sense.
| dcrazy wrote:
| Those should be tightly integrated, if not the same tool.
| nine_k wrote:
| 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 wrote:
| 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
| ndegruchy wrote:
| +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
| sudoforge wrote:
| 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 wrote:
| 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.
| eikenberry wrote:
| 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.
| WD-42 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pacifika wrote:
| Might be interesting as a personal cross project todo tracker?
| tiffanyh wrote:
| Interesting that GPL3 was selected for this, while Git itself is
| GPL2 (these are incompatible licenses)
| chungy wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 [1]:
| https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...
| IshKebab wrote:
| Interesting, thanks. This must be true though right?
|
| > Am I going to find replies magically appearing before mine?
| tuckerman wrote:
| I would think in general yes, but hopefully not like the
| example you gave because I would expect if you are replying
| to a comment, your clock would fast-forward past the
| timestamp of the original comment (NB I haven't looked at
| OP's implementation).
| spoonsort wrote:
| Just the fact that I can use it without a website is a game
| changer.
| rzwitserloot wrote:
| 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 wrote:
| 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 (see https://news.y
| combinator.com/from?site=github.com/michaelmur...)
| sudoforge wrote:
| you aren't alone! linus thinks we need this, too:
|
| https://youtu.be/sCr_gb8rdEI?t=1533
| stratosgear wrote:
| Docs seem to miss instructions on how you add a bug! Did I miss
| it?
| dannyfritz07 wrote:
| https://github.com/git-bug/git-bug/blob/master/doc/md/git-bu...
| binary132 wrote:
| 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 wrote:
| > 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.
| layer8 wrote:
| 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
| sudoforge wrote:
| 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/bd936650ccf44ca33cf9...
| bognition wrote:
| 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.
| fundaThree wrote:
| TUI?
|
| EDIT: "rich terminal users interfaces"
| gapan wrote:
| > TUI?
|
| Text User Interface
| dannymi wrote:
| There's also https://github.com/dspinellis/git-issue which has
| much fewer dependencies.
| johanbcn wrote:
| 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__ wrote:
| 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 wrote:
| Excited to try this. I like the look of that TUI.
___________________________________________________________________
(page generated 2025-05-14 23:00 UTC)