cache update on push in hosting situation #409

I think the problem we're more worried about is whether it actually refreshes the running web UI if the folder it looks at is changing simultaneously. Our setup would most likely point the running process directly at a Gerrit repository on disk, which is the actual .git that pushes end up happening to. This is fairly easy to figure out though.

So you want to accept edit from both the webUI and git bug push at the same time. That make sense.

When the webUI or any other command run, the cache lock the repo, which prevent any other command to process. Any ... but a push as this is git itself, not git-bug. It works well for a personal usage: you can't alter the repo concurrently and you can't pull new changes while something else happen. This mechanism doesn't protect from pushes though, which is a problem in hosting situation.

The other problem is indeed that the cache is at the moment not aware that a push happen and won't invalidate or update the entities in memory or update the index.

Maybe a server-side git hook could solve that ? This hook would monitor git pushes, look if a git-bug entity has been updated, and inform the running process (the one started with webui) of that through an additional API endpoint. The cache would then perform the required invalidation.

Originally posted by @MichaelMure in #407 (comment)