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.
It’s unclear to me what you mean.
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
Some days ago, on the Firefox mover to github topic, people were wondering if issue trackers should also be distributed.
Seems an interesting idea.
Similarly things like automatically promoting bugs into the test suite as SHOULD FAIL and so on
hungryhobbit•7h ago
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.
hungryhobbit•7h ago
jFriedensreich•6h ago
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
cryptonector•4h ago
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.
Git-Master•2h ago
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.
cryptonector•1h ago
I thought that Fossil did or at least aimed to support different SQL RDBMSes. Did that go away at some point?
jFriedensreich•2h ago
cryptonector•5h ago
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.
hosh•6h ago
bluGill•6h ago
baq•5h ago
XorNot•38m ago
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.
pixl97•2h ago
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.
devrandoom•6h ago
whateveracct•6h ago
dcrazy•6h ago
nine_k•4h ago
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.
chungy•6h ago
[0]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
ndegruchy•5h ago
It just needs some more 'modern' themes
sudoforge•5h ago
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
layer8•4h ago
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.
eikenberry•2h ago