[sudoforge]

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

[IshKebab]

Interesting, thanks. This must be true though right?

> Am I going to find replies magically appearing before mine?

[michaelmure]

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.

[IshKebab]

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

[michaelmure]

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.

We are not there yet but it's really not far.

[sudoforge]

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]

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.

[tuckerman]

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