Is push access required?

[sio]

I didn't find it mentioned in the documentation, but if I understand correctly, any user wishing to open a new issue or to comment on existing one must have push access to the repository. Is that correct? Are there any workarounds to allow untrusted users to participate?

Thank you!

[MichaelMure]

As of now, that's correct. Of course it would be super useful to be able to accept edition from people without push access. The plan is to make the webui into a portal that can be exposed on the public internet, and accept various auth system (github oauth, ...). But someone would need to help building the webui. The graphql API is here but there is work to do on the frontend.

[sio]

Thank you :-)

[GlancingMind]

I have another idea which could allow users to contribute bugs (or other entities) without requiring push access to the hosted repository and without requiring to host a WebUI instance of git-bug. But first let me clarify, why another option besides the WebUI should available.

Ideally the WebUI should be available 24x7 by potential contributors. As the WebUI needs a running instance of the backend, hosting is required. But (self-)hosting requires money and knowledge. I think this problems can be solved by supporting the existing email infrastructure, which is accessible 24x7 while also being usable without spending money.

Let me describe a use-case.

Alice wants to send a bug to Bob's repository which is hosted on GitHub.
Alice (git) clones the repository, pulls the bugs and open a new bug via git-bug.
Notice, that Alice is a stranger to Bob and has no push privilege to his GitHub repository.
Problem: Alice now has her bug report but cannot push it directly to Bob.
Solution (just pretend that following is possible):
Instead of using git-bug push, Alice calls git-bug send.
git-bug send prepares a specific email of the new created bug and send it to Bob's repository email.
When Bob goes online, he can call git-bug receive, which will checks the repositories email account about new git-bug formatted emails.
He then can proceed to incorporate Alice's bug into his git-bug repository or ignore/reject it.
Alice could then be informed via email, that her bug was added or rejected.
The last thing to do for Bob would be to push the bugs received via email to his GitHub repository, so that every other contributor can pull Alice bugs, too.

Further considerations

• Above design is not restricted to the exchange of bugs. PRs could also be shared this way or other entities.
• If the git-bug repository does not contain an email address to send bugs (must be added by Bob), git-bug send will be disabled.
• A bug does not have to be send with the email. It should also work to have a URL to Alice's public repository, which then Bob could pull the specified bug from. (Similar to sending a patch file vs request a pull).
• git-bug recieve -watch flag could be introduced to constantly watch the email account for new git-bug entities.
• git-bug send/recieve <remote> could be used to only communicate with known forks (e.g. Alice could send a permission to register her public GitLab repository as fork of Bob's).
• Emails send via git-bug should have a verifiable format so that the user never has to filter git-bug emails from other emails in the mail account. Ideally the user would have one email account just for git-bug (maybe per repository).
• Possible that email can be replaced with any kind of asynchronous communication protocol.

Conclusion

By leveraging the email infrastructure git-bug could become hosting independent, while still staying compatible with git-bug push/pull and the WebUI. Maybe we need this feature anyway to exchange PRs in the future as push access is not always possible.

PS: Let me know, if something is unclear. Would also like to hear, what other users of git-bug think about this idea.
At least I would really like to have this feature (in this or similar form).

[rng-dynamics]

Your idea reminds me a bit of git format-patch (https://git-scm.com/docs/git-format-patch). I am wondering whether it would be useful to compare your idea with it.

[GlancingMind]

Yes, git format-patch and git request-pull was my inspiration :)
Unfortunately go-git seems to not support the "email workflow".
https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md

[MichaelMure]

I get the idea but I'm not sure it's solving an actual problem. Or at least I'm not sure it's solving enough of a problem to be not be considered feature creep. Here is how I see things, please poke hole in it from your point of view:

There is two big patterns for users of git-bug: [A] a small/private group, and [B] a public project.

[A] Small/private groups:

• either a single dev, a tiny group of people or a project that doesn't need/want external input
• everyone has git push access
• can exchange bugs internally through git
• doesn't need a public webUI, or at least not write enabled

[B] Public project:

• require public visibility and public input
• want to deploy the webUI
• maintainer/core contributor have push access
• everyone else can use the webUI

Now to address the need of [B], the webUI should be as simple to deploy as:

1. get a cheap hosting environment
2. run git bug webui --online on it
3. point a DNS to it

... or alternatively, a commercial entity or free provider start to offer git-bug hosting.

So to me, most of the use-cases seems covered. I could see this workflow working but at the same time, receiving/sending emails from your computer is usually a major pain. Much more than having a single person setup the webUI.

On a side note, git format-patch ..refs/bugs/xxxxx does pretty much work. I'm not sure how the receiving end should process the result but all the data (but the identities) is there.

[GlancingMind]

, receiving/sending emails from your computer is usually a major pain. Much more than having a single person setup the webUI.

True, that is why I think, the workflow should be as autonomous as possible. The user shouldn't be required to check the emails out and apply the changes individually. The system should take care of this. The general infrastructure should already exist with the email being given for the git-bug identity and go's support for sending email. The nice thing is, that the system could co-exists with the other use-cases. And it would make it possible to contribute to a public repository [B] with the cli/termui.
On the other hand, I'm still lacking the knowledge to estimate the implementation effort. :-)

For now, I agree that your mentioned use-cases are the dominating ones and should be prioritized.
But I also pledge to not drop the coin to early and at least hold it in mind, for the point when the other options have matured enough. (I hope, that I don't come off to pushy 😬)

... or alternatively, a commercial entity or free provider start to offer git-bug hosting.

Oh yeah, business opportunity 👨‍💼 💼

[MichaelMure]

The general infrastructure should already exist

That's the key point really. How many people have that?

The nice thing is, that the system could co-exists with the other use-cases.

Yes. In a way it's just another transport. And it doesn't even have to be implemented in git-bug itself.

But I also pledge to not drop the coin to early and at least hold it in mind, for the point when the other options have matured enough. (I hope, that I don't come off to pushy grimacing)

Not at all, that's the right mindset. I'm just a random guy from the internet trying to make a cohesive and good software. I don't know everything and external point of view is very valuable. Also, I'd like to make this project one that people feel like adopting as their own, for their workflow but also to hack and improve on.