Hi, I'm working on a Docker-image to help users deploy their own git-severs including common services like code-browsing/wikis etc easily.
Since I use git-bug myself, I was thinking of using it as a service instead of bridging (git-bug webui --no-open -p <number>). This suits the purpose of both not lock-in projects and to enable use behind stringent network policies enabling users to deploy their stuff locally.
I've experimented on a server-side git repo and git-bug seems to work as normal. It's state-less (apart from the intended statefullness select and user adopt) which is principally good. But it has the drawback of that it's not possible to select user without starting another process running git-bug user adopt xxxx first and then use the port-option for parallel processes as do differentiate users.
What I'm wary about is the following:
Will git bug run with several users simultaneously in the same directory be able to handle that (i.e. are operations atomic etc enough)?
Using port-option to differentiate states of operation is awkward. One way to achieve this is to wrap git-bug in a service-daemon and redirect GET/PUT requests to different processes accordingly. But it still leaves the first question unanswered.
I think CGI-parsing handled by git-bug itself would be better. It keeps service closer to the inner logic which should make it easier to figure out corner-cases. It also makes it much easier to lock operation when git-bug is busy updating git states. It should (I hope) hence be a somewhat low hanging fruit - provided that my conclusions based on the experimentation are correct ofc.
Note that I'm thinking low volume access first hand. For high volume projects, I'm sure projects can afford on premise to Jira/Gitlab etc using bridging solutions instead.
Michael Muré (MichaelMure) commented
It's planned but not yet functional that the webUI would have an optional login step to either 1) select an existing user or even 2) generate git-bug users from an external authentication provider (say, github oauth). The user ID would then be stored in a cookie or something, like any other web app.
See https://github.com/MichaelMure/git-bug/tree/master/api/auth for the existing code about that: at the moment the webUI use a fixed user, the one active on the command line. You could implement a new middleware with those multi-user feature.
Another problem you will have when running as a server is that git-bug is not aware of normal git push if you expose it to your users. This means that if someone use git bug push to push bugs changes, the webUI will not be aware of it unless restarted. We would need some kind of git hook to fix that problem.
Michael Ambrus (mambrus) commented
Nice! Your reply answers a few questions actually. Mainly that parallell accessing using multiple servlets (one per user) would not be a good idea. It would scale horribly badly and would probably still be race-condition prone. Managing only two (the use-case described of git bug push- i.e. server-side git itself and ONE git-bug service-daemon) is manageable though. In combination with git-hooks, feature could be solved by serialising requests into sessions (i.e. making the service itself stateful/state-aware). But it's a detour and I like your thinking much better, especially since it also covers creation of new users and authorisation.
Perhaps not a low hanging fruit though?
Unfortunately I don't know go or I'd be willing to lend a hand.
Do you have a ticket-number? I'd be happy to have a look and if deemed duplicate/overlapping we can close this one.
github-actions (github-actions) commented
This bot triages untriaged issues and PRs according to the following rules:
After 90 days of inactivity, the lifecycle/stale label is applied
After 30 days of inactivity since lifecycle/stale was applied, the issue is closed
Michael Muré (MichaelMure) commented 
github-actions (github-actions) commented