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.

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