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 :)
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).
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.
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.
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]?
I create issues for myself. I sometimes create branches with informal issue keys like `<three letters>-<incrementing number>`. I use `git bug webui` to type edit issues. That’s it.
All I would like as a nice-to-have is support for making those issue keys that I use automatic. For me it’s all local to me so it doesn’t need to be globally unique. But those N-letter prefix does make collision less likely on a single project. I’ve mentioned it here: https://github.com/git-bug/git-bug/issues/75#issuecomment-19...
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.
> 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.
In theory it could happen but it's unlikely in practice, for multiple reasons:
- git-bug use a form of logical clock (not wall clock) that order an action in relation to other actions in the repo. Clock drifting doesn't matter.
- pushing to git usually require some access to the repo, and therefore abuse can be dealt with socially (aka you get kicked out)
What can happen for example is someone write a comment, shut down the computer and only push the next day, but in that case the comment showing up before yours is the correct merging.
> pushing to git usually require some access to the repo
Wait, so to comment on an issue I now have to already have push access to that repo? How does that work? E.g. what if I want to comment on a VSCode issue? I'm not a VSCode developer...
Right now, yes, but the idea is to augment the webUI with external auth (e.g. Github OAuth and others) to make it a public portal where anyone can create issues and so on. In that case, the webUI would have access to the git repo, enforce any rules and prevent abuses.
With a single binary deployment, you'd just need a bit of config and a DNS, and you could host a forge-ish for your project.
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.
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.
I would think in general yes, but hopefully not like the example you gave because I would expect if you are replying to a comment, your clock would fast-forward past the timestamp of the original comment (NB I haven't looked at OP's implementation).
honestly cleaning up the Readme and documentation would go a very long way, right now all the information feels fragmented behind all of the little pages. I clicked into the documentation and clicked the first link presented to me on each page and 5 clicks or so in I was on the command line docs but I hadn't seen anything that gave me a high level overview of what git-bug is, what it does, why I want to use it, etc...
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.
This would be amazing as a Magit module for Emacs. I don’t relish the idea of using it in a terminal alongside Emacs while using Git from inside Emacs. Is there a lower-level interface that Magit could provide a porcelain for, maybe?
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?
Magit is a Git porcelain for Emacs that implements an interactive TUI. It uses the lower-level APIs Git exposes, I think via the shell but I’m not positive. I’m really just saying if there’s not a primitive API for third-party interactive porcelains to use, that should be part of the design picture! :)
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)
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.
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 :)