Why is read-only webui still locking the access to git bug? #1570

Hey Yessen,

I think the confusing part is that --read-only currently means “make the Web UI/API read-only”, not “open the repository through a non-locking read-only backend.”

The WebUI still creates a RepoCache, and that cache takes the repository lock for as long as the WebUI server is running. So other git-bug CLI commands see the repo as locked by that process and refuse to continue.

That looks like a current architectural limitation rather than intended “read-only should block writers” behavior.

The proper fix would probably need:

• separate read/write locking
• shared read locks for read-only clients
• exclusive write locks for CLI/WebUI mutations
• cache invalidation/reload when another process writes
• possibly a snapshot mode for truly read-only browsing

For now, the practical workaround is to run the read-only WebUI from a separate clone/mirror and do read-write CLI work in your normal clone, then sync between them.

Relevant bits:

• WebUI --read-only still registers the repo cache: https://github.com/git-bug/git-bug/blob/master/commands/webui.go
• Cache layer locks the repo while active: https://github.com/git-bug/git-bug/blob/master/cache/repo_cache.go
• Maintainer comment about current locking model: A vision for the future of git-bug #1391 (comment)