sudoforge
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
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.
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 :)
is a "magit module" roughly synonymous with a vim plugin? if so, then would shelling out to the CLI work?
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...
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.
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.
- 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.
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.
> 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...
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...
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
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.