Live data from Hacker News

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

github.com

31–40 of 110 posts

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

#31
post #27

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

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

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.

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

#32

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

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

#33

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

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

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

#34

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.

you aren't alone! linus thinks we need this, too:

https://youtu.be/sCr_gb8rdEI?t=1533

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

#37
post #5

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.

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.

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

#38

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

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

Interesting, thanks. This must be true though right?

> Am I going to find replies magically appearing before mine?

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

#39

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

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.

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

#40
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.

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