sudoforge

6 ms·

1.
by sudoforge 5mo ago
Thanks for the kind words!
2.
by sudoforge 5mo ago
> For me the main issue with git-bug is that they are not dogfooding it. This is incorrect. $ git remote get-url origin ssh://git@github.com/git-bug/git-bug.git $ for n in bugs identities; do echo &quot
3.
by sudoforge 9mo ago
hey, git-bug maintainer here! just to address the package management situation on linux: i currently use nixos, and previously ran arch linux for over a decade. the AUR package is community maintained, as is the nixpkgs package (i maintain
4.
by sudoforge 1y ago
hrm... what's your current workflow like? if there's anything you think git-bug could be doing to make that workflow easier, would you mind hopping in our matrix channel [1], or opening an issue [2]? [1]: https://matrix
5.
by sudoforge 1y ago
i have no understanding, beyond that of a lexical nature, what a "magit module" is. i'm a (neo)vim user, and heavy terminal junkie, and if i wanted to build a vim plugin for git-bug, that plugin would likely be shelling out t
6.
by sudoforge 1y ago
looks neat! if you're interested in working on this sort of technology, git-bug needs more maintainers! (i also personally wouldn't mind a rust port, and have poked at this in the past).
7.
by sudoforge 1y ago
maintainer here. great question! git-bug embeds a "lamport timestamp" [0] - that is, a logical clock, not a wall clock - in each operation (like the creation of a bug, or a comment, or an edit to a comment). this, combined with th
8.
by sudoforge 1y ago
awesome to see a user in the wild! if you weren't aware, you can publish your git-bug issues to the project's issue tracker, assuming that it's on one of the supported bridges today (github, gitlab, jira). the bridges exist w
9.
by sudoforge 1y ago
git-bug is built to be portable - today, the way git-bug interacts with other platforms which do not support reading from its namespaces directly is through bridges. right now, git-bug has built-in bridges for github, gitlab, and jira. i am
10.
by sudoforge 1y ago
to support the workflow where you, an individual, outside contributor, want to use git-bug to create or comment on an issue on a third-party platform that you do not control, you would: - install git-bug - create a directory (and `git init`
11.
by sudoforge 1y ago
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, a
12.
by sudoforge 1y ago
you aren't alone! linus thinks we need this, too: https://youtu.be/sCr_gb8rdEI?t=1533
13.
by sudoforge 1y ago
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,
14.
by sudoforge 1y ago
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 curr
15.
by sudoforge 1y ago
hey! maintainer here. 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
16.
by sudoforge 1y ago
hey there! i maintain git-bug, and recently trimmed down the README, which was, in my opinion, a bit too dense prior to this recent change ( https://github.com/git-bug/git-bug/commit/96c7a111a3cb075b5c... ). i