Docs seem to miss instructions on how you add a bug! Did I miss it?
Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
21–30 of 110 posts
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#22This 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 peo…
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.
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#23It’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.
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#24While 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?)
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.
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#25I'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.
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.ycombinator.com/from?site=github.com/michaelmur...)
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#26Earlier quoted context omitted.
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 interoperabili…
> "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.
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#27Some screenshots would be nice. I found this one [0] of the TUI from 2018, but not much else.
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#28Earlier quoted context omitted.
This is a bug tracker. What you are describing is much closer to a project management tool, just to make the difference clear.
Those should be tightly integrated, if not the same tool.
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.
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#29While 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-…
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.
Re: Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges
#30Some 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
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...