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

51–60 of 110 posts

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

#51

Post by XorNot »

baq wrote: post #14
bluGill wrote: post #5

Earlier quoted context omitted.

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.

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.

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

#53

Post by binary132 »

kgeist wrote: post #40
binary132 wrote: post #20

Earlier quoted context omitted.

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

I know there are workarounds, I’m talking about the general principle or the situation at large.

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

#55

Post by binary132 »

sudoforge wrote: post #30
layer8 wrote: 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...

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?

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

#56

Post by yogsototh »

rzwitserloot wrote: post #19

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.

I had the same idea for a talk a long time ago the result is 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.

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

#57

Post by AceJohnny2 »

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

[2] https://gerrit-review.googlesource.com/Documentation/config-...

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

#58

Post by michaelmure »

AceJohnny2 wrote: post #57

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

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/da... and 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.

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

#59

Post by michaelmure »

IshKebab wrote: post #38
sudoforge wrote: post #33

Earlier quoted context omitted.

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?

In theory it could happen but it's unlikely in practice, for multiple reasons:

- git-bug use a form of logical clock (not wall clock) that order an action in relation to other actions in the repo. Clock drifting doesn't matter.

- pushing to git usually require some access to the repo, and therefore abuse can be dealt with socially (aka you get kicked out)

What can happen for example is someone write a comment, shut down the computer and only push the next day, but in that case the comment showing up before yours is the correct merging.

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

#60

Post by sudoforge »

IshKebab wrote: post #38
sudoforge wrote: post #33

Earlier quoted context omitted.

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?

no - this is what using a lamport timestamp helps to avoid.

edit: re-read your comment and i see what you're getting at.

yes, there is the chance that you don't interact with the remote for X days, and neither does someone else, and when you both finally do, their comment will "magically show up before yours" because in reality they _did_ leave the comment before you.

this is not dissimilar to looking at normal git commits ordered by "author date" vs. "commit date", and seeing "weird date ordering" in a linear tree.

git-bug shows items in "the real order", so in a workflow where you are not fetching frequently, yes, other peoples' activity may be applied before yours when you finally do.

this is just like on a centralized platform like github, where if you are writing a lengthy response or review of a PR, you can end up posting it and requesting changes or approving it after the PR has been merged.

Post reply on HN