71–80 of 110 posts
It’s very weird seeing the coping / seething about a useful tool like this even in HN comments. People have really drunk the proverbial kool-aid / joined the dark side.
Earlier quoted context omitted.
Interesting, thanks. This must be true though right? > Am I going to find replies magically appearing before mine?
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 d…
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...
Earlier quoted context omitted.
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 d…
> 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...
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.
Earlier quoted context omitted.
Fossil[0] has bug tracking as a standard feature, and through the HTTP role-based authentication, you are able to set up users with different privileges; for instance, being able to read and write the bug tracker without the ability to push new code. [0]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
+1 for this. I love having a self-contained, syncable GitHub-lite. It uses SQLite for the format, too, which makes it easy to discover the internals. It just needs some more 'modern' themes
My chance at sharing Fossil is not Relational. The two times it's been submitted to HN it didn't gain votes.
https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...
This looks cool and has the opportunity to replace my old and trusted todo.txt, but I couldn’t find how to create or resolve bugs. The CLI has features related to syncing but nothing about this, or did I miss something?
You can find creation here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi...
And status update here https://github.com/git-bug/git-bug/blob/master/doc%2Fmd%2Fgi...
How do you handle conflict resolution when multiple users modify the same issue or thread concurrently across remotes? Is it purely Git's merge mechanics, or do you apply any domain-specific heuristics?
Earlier quoted context omitted.
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 d…
> 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...
- 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.
Imagine having repository issues seamlessly propagated and replicated across all your git mirrors.