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

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