sudoforge · HackerTrans

Thanks for the kind words!

> For me the main issue with git-bug is that they are not dogfooding it.

This is incorrect.

    $ git remote get-url origin
    ssh://[email protected]/git-bug/git-bug.git

    $ for n in bugs identities; do echo "${n} on the remote: " $(git ls-remote origin "refs/${n}/\*" | wc -l); done
    bugs on the remote:  453
    identities on the remote:  311

See the related issue for more info: https://github.com/git-bug/git-bug/issues/1221#issuecomment-...

That said, yes, GitHub is still our source of truth, as our web application does not currently support "guest" access, and there are other platform features that our community uses that we do not currently have support for (e.g. discussions and pull requests). Big changes to the web ui are coming soon, which will help to unlock the ability to do these things.

I've also been in talks with the Radicle team about possible collaboration.

sudoforge

6 ay öncediscuss

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 it though, so the community doesn't really need to here).

making installation simple on other, more commonly used distributions is a goal, but is less of a priority at the moment than feature work and bug fixes. we're very open to package maintainers on those distributions packaging git-bug, however :)

sudoforge

geçen yıldiscuss

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.to/#/#git-bug:matrix.org

[2]: https://github.com/git-bug/git-bug/issues

sudoforge

geçen yıldiscuss

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 to the command line (as git-bug doesn't expose an independent API today -- it's only started when you start the web ui).

is a "magit module" roughly synonymous with a vim plugin? if so, then would shelling out to the CLI work?

sudoforge

geçen yıldiscuss

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).

sudoforge

geçen yıldiscuss

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 the data model [1] we use, allow activity to be recorded and replayed without ever encountering a merge conflict.

[0]: https://en.wikipedia.org/wiki/Lamport_timestamp

[1]: https://github.com/git-bug/git-bug/blob/master/doc/design/da...

sudoforge

geçen yıldiscuss

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 within git-bug to support adoption of the tool and interop with existing platforms.

`git bug bridge pull` and `git bug bridge push` use the bridge's API, and don't attempt to pull from or push to the git remote.

sudoforge

geçen yıldiscuss

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 working on the design for a more modular system in which bridges can be built by anybody and used as "plugins".

really, though, the better, long-term goal is to work with $PLATFORMS to have them update their issue tracker to use git-bug's issues (that is, read from and publish to the refs/bugs namespace using git-bug). there's a bit missing right now to make this easy, but it's something that's very much top of mind as i think about git-bug's future.

sudoforge

geçen yıldiscuss

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`), optionally fetch/clone the remote repo (but this is not needed)

- create a git-bug identity (`git bug user new`)

- configure a bridge to (for example, using vscode) github (`git bug bridge new`)

- pull issues from the bridge to your local repository's refs/bugs namespace (`git bug bridge pull`)

- create a new issue, or browse existing ones and comment on them at will

- export your activity to the bridge (`git bug bridge push`)

this works without push access to the repository, because when importing to or exporting from a bridge, the API credentials you provide when configuring the bridge are used -- `git bug bridge {push,pull}` does not push your local `refs/bugs` to the remote.

sudoforge

geçen yıldiscuss

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, and when you both finally do, their comment will "magically show up before yours" because in reality they _did_ leave the comment before you.

this is not dissimilar to looking at normal git commits ordered by "author date" vs. "commit date", and seeing "weird date ordering" in a linear tree.

git-bug shows items in "the real order", so in a workflow where you are not fetching frequently, yes, other peoples' activity may be applied before yours when you finally do.

this is just like on a centralized platform like github, where if you are writing a lengthy response or review of a PR, you can end up posting it and requesting changes or approving it after the PR has been merged.

sudoforge

geçen yıldiscuss

you aren't alone! linus thinks we need this, too:

https://youtu.be/sCr_gb8rdEI?t=1533

sudoforge

geçen yıldiscuss

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, 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...

sudoforge

geçen yıldiscuss

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 currently live in: https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...

sudoforge

geçen yıldiscuss

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 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

sudoforge

geçen yıldiscuss

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 rewrote the README with the goal of providing a clear overview of git-bug's features, and why you might want to use it, and ensuring that for those who are more technically inclined, things like the data model, internal architecture, and more were easy to find under the documentation folder (whether you're browsing through the files directly, or landing on //doc:README.md, which links to the files and folders under //doc.

if you think that there is information missing from the README, or hard to find in the repository (either by browsing through it, or clicking the rather prominent links from the main README), i'd welcome any suggestions in the form of a PR.

comments