Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

11–20 of 110 posts

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

#11

Post by chungy »

hungryhobbit wrote: post #2

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-…

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

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

#12

Post by jFriedensreich »

hungryhobbit wrote: post #3
hungryhobbit wrote: post #2

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-…

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

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

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

#14

Post by baq »

bluGill wrote: post #5
hungryhobbit wrote: post #2

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-…

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.

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.

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

#15

Post by chungy »

tiffanyh wrote: post #13

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

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.

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

#16

Post by sudoforge »

hungryhobbit wrote: post #2

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-…

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

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

#17

Post by ndegruchy »

chungy wrote: post #11
hungryhobbit wrote: post #2

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-…

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

+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

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

#18

Post by IshKebab »

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.

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

#19

Post by rzwitserloot »

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.

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

#20

Post by binary132 »

WD-42 wrote: post #6

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.

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.
Post reply on HN