3 ms·
> 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 wor
by 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 agoRight 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 2y agoto 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.