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.
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-featured tracker designed for everyone to use.
But, I am curious to hear from someone who has actually used this thing.
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.
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.
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)
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.
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.
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
> "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.
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 (via auxiliary tables) to speed up queries, but these tables are transient, get updated by inserting new artifacts, and can be regenerated from the artifacts.
(Users and their metadata, and configuration is not part of this scheme, so these tables might be viewed as relational tables. They are local-only; and not synced.)
I don't think that is the main issue. Its not THAT hard to build a secondary sqlite index for data stored in git and keep in in sync especially because the data is already versioned and can be incrementally updated.
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.
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.
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.
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.
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.
> 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.
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.
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.
[0] https://github.com/git-bug/git-bug/releases/tag/0.4.0
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...
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.
EDIT: "rich terminal users interfaces"
Text User Interface
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-featured tracker designed for everyone to use.
But, I am curious to hear from someone who has actually used this thing.
[0]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
It just needs some more 'modern' themes
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.
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
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.
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.
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
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.
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 (via auxiliary tables) to speed up queries, but these tables are transient, get updated by inserting new artifacts, and can be regenerated from the artifacts.
(Users and their metadata, and configuration is not part of this scheme, so these tables might be viewed as relational tables. They are local-only; and not synced.)
See https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details.
2. There are no other databases like PostgreSQL to choose from.
I thought that Fossil did or at least aimed to support different SQL RDBMSes. Did that go away at some point?
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.
It’s unclear to me what you mean.
Some days ago, on the Firefox mover to github topic, people were wondering if issue trackers should also be distributed.
Seems an interesting idea.
I have doubt it'll happen. GitHub/GitLab culture is pretty strong, few seem interested in having distributed project management features.
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.
> 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...
> Am I going to find replies magically appearing before mine?
This is wildly exciting.
https://youtu.be/sCr_gb8rdEI?t=1533