3 ms·

This really seems like an odd thing to make distributed. Do I now have to resolve conflicts in bug conversations? Am I going to find replies magically appearing

This really seems like an odd thing to make distributed. Do I now have to resolve conflicts in bug conversations? Am I going to find replies magically appearing before mine? The README doesn't even acknowledge that these difficulties might exist. This sounds like it adds a ton of potential problems and solves some very minor ones: * You can work offline. Great, but 90% of bug tracking is sending messages to other people so that's not particularly useful. * You aren't tied to GitHub Issues or whatever. I guess that's good. Seems pretty marginal though.

riedel 2y ago
I think there is multiple cases where repos are mirrored between Codeberg, GitHub and internal and public instances of Gitlab. People want to open issues where they are and they can get accounts. Also I had to migrate issues from one repo to the other. Having wikis moved to git repos is a big advantage over trac and redmine (we just recently moved old projects and it is a pain each time). So I highly welcome anyone who moves issue tracking to git as well.
sudoforge 2y ago
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 https://en.wikipedia.org/wiki/Lamport_timestamp [1]: https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...
- IshKebab 2y ago
  Interesting, thanks. This must be true though right? > Am I going to find replies magically appearing before mine?
  - tuckerman 2y ago
    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).
  - michaelmure 2y ago
    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 2y ago
      > 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 2y ago
        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.
spoonsort 2y ago
Just the fact that I can use it without a website is a game changer.

riedel 2y ago

I think there is multiple cases where repos are mirrored between Codeberg, GitHub and internal and public instances of Gitlab. People want to open issues where they are and they can get accounts. Also I had to migrate issues from one repo to the other. Having wikis moved to git repos is a big advantage over trac and redmine (we just recently moved old projects and it is a pain each time). So I highly welcome anyone who moves issue tracking to git as well.

sudoforge 2y ago

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 https://en.wikipedia.org/wiki/Lamport_timestamp [1]: https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9c8bf553fe090534d2ab3/doc/design/data-model.md https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...

IshKebab 2y ago
Interesting, thanks. This must be true though right? > Am I going to find replies magically appearing before mine?
- tuckerman 2y ago
  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).
- michaelmure 2y ago
  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 2y ago
    > 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 2y ago
      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.

spoonsort 2y ago

Just the fact that I can use it without a website is a game changer.