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

61–70 of 110 posts

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

#61

Post by chungy »

cryptonector wrote: post #47
Git-Master wrote: post #41

Earlier quoted context omitted.

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

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?

Fossil's "file format" is not intimately tied to SQLite: https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki

That being said, it's the only existent implementation and none other are planned. If you'd like to port it to PostgreSQL, go for it, but it probably would lose a lot of the appeal of being a distributed version control system.

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

#62

Post by farhanhubble »

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…

Wow!So this can be used for full blown project management too.

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

#63

Post by alasr »

Git Bug screenshots:

- TUI recording (GIF): https://github.com/git-bug/git-bug/blob/master/doc/assets/tu...

- Web comments (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/we...

- Web feed (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/we...

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

#64

Post by alchemist1e9 »

farhanhubble wrote: post #62
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…

Wow!So this can be used for full blown project management too.

Could you expand on how you see that working? combining these extensions is what I’m guessing but I’d be super interested in hearing how it might work.

If all information for an asynchronous development process could be stored into git and distributed by it, this would be a very good idea for many projects.

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

#65

Post by michaelmure »

alchemist1e9 wrote: post #64
farhanhubble wrote: post #62

Earlier quoted context omitted.

Wow!So this can be used for full blown project management too.

Could you expand on how you see that working? combining these extensions is what I’m guessing but I’d be super interested in hearing how it might work. If all information for an asynchronous development process could be stored into git and distributed by it, this would be a very good idea for many projects.

So for example, git-bug already has a PR to add support for a project board: https://github.com/git-bug/git-bug/pull/843

The same way, one could add support for code review (aka PRs), todo list, custom entities that your workflow need (say, tracking documentation or custom requirement) ... It can also be entirely outside of the development process.

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

#66

Post by imoverclocked »

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…

Is there a registry of namespaces to avoid collisions?

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

#67

Post by freddie_mercury »

cryptonector wrote: post #24
hungryhobbit wrote: post #3

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

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…

> Fossil was the first tool to put bug tracking in the repository

I'm pretty sure Aegis did it 15 years before Fossil.

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

#68

Post by eliaspro »

michaelmure wrote: post #65
alchemist1e9 wrote: post #64

Earlier quoted context omitted.

Could you expand on how you see that working? combining these extensions is what I’m guessing but I’d be super interested in hearing how it might work. If all information for an asynchronous development process could be stored into git and distributed by it, this would be a very good idea for many projects.

So for example, git-bug already has a PR to add support for a project board: https://github.com/git-bug/git-bug/pull/843 The same way, one could add support for code review (aka PRs), todo list, custom entities that your workflow need (say, tracking documentation or custom requirement) ... It can also be entirely outside of the development process.

This would allow for really native linking between a tracked issue and corresponding commits/branches/tags, for modeling dependencies between issues as part of the git DAG,...

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

#69

Post by mirekrusin »

imoverclocked wrote: post #66
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…

Is there a registry of namespaces to avoid collisions?

Technically you could solve collisions through single indirection convention ie 'refs/manifest' which describes refs used with their "schema", "version" etc. If you want to decorate your repo with something, you'd register it there. This way you wouldn't have to keep global convention registry for different projects not to step on each other.

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

#70

Post by baq »

layer8 wrote: post #29
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-…

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.

It’s expensive to maintain more front ends than you absolutely require. Web+mobile is one too many already.
Post reply on HN