81–90 of 110 posts
I appreciate that tools like Git Bug are not tied to a single repo host but they are tied inherently to a single VCS (git). BE was not reliant on a specific VCS, and it's a *really* simple format on-disk too.
Earlier quoted context omitted.
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…
It's a little disappointing that BugsEverywhere/BE ( https://github.com/aaiyer/bugseverywhere ) never gained popularity. I appreciate that tools like Git Bug are not tied to a single repo host but they are tied inherently to a single VCS (git). BE was not reliant on a specific VCS, and it's a *really* simple format on-disk too.
Or you could just as well plug a generic database there.
[1]: https://github.com/git-bug/git-bug/blob/master/repository/re...
Earlier quoted context omitted.
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 hoste…
> just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB
Applications with SQL backends tackle the problem “how can we express our CRUD datastructures so they fit the relational model?
When you replace SQL with a file-based serialised format, you mainly lose ACID. This is arguably easier than SQL.
You are a single user locally: as long as your IDE plugin doesn’t fight with your terminal client, your need for ACID are low: you handle conflicts like git conflicts, but you may apply domain-specific conflict resolution; while conflicts in source code has no general resolution strategy, merging issue comments can be easy; changing issue status when people agree can be automatically resolved; handling conflicts manually can be tool-assisted.
So losing SQL is not that big of a deal, assuming you’re in a highly decentralised, highly async environment.
The answer to “Why though?” should be forge interop, keeping knowledge in-repo, and because it may fit the organisation (or lack of), e.g. just like you can commit code changes offline, you’re not prevented from updating issues when you’re offline.
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.
Maybe because it’s less useful than you think. Companies and large orgs won’t be using it because they like centralized and on the small side your competition is a bunch of TODO files, not a bug tracker.
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-…
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?)
Not being Jira is already a huge benefit. It says offline, local first. Isn't that nice?
This looks cool and has the opportunity to replace my old and trusted todo.txt, but I couldn’t find how to create or resolve bugs. The CLI has features related to syncing but nothing about this, or did I miss something?
If you're looking at the CLI there are specific man pages for it. You can find creation here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi... And status update here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi...
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-…
From QA perspective, which is the one the closest to me: I wanted such a tool for many years, and even though I haven't tried this specific one, I endorse the idea with both of my hands.
In the context of QA, it's always a problem to coordinate between test development, feature development, feature description, and tracking the work progress. All bug trackers I used to date are awful at it. This has a potential to solve at least part of the problem by being physically connected to the work done by either development or QA, or, ideally, both. The holy grail here is the ability to determine what tests to run in response to a commit without making it too much of a burden on the committer.
Tests can easily be the most expensive ongoing activity a development company may undertake. In this context, being able to avoid running useless but expensive tests is very desirable.