Thanks for the insights! > For products you're developing that involve multiple repositories, it's possible to use a "meta repository"[1] to establish what's c

Thanks for the insights! > For products you're developing that involve multiple repositories, it's possible to use a "meta repository"[1] to establish what's called a login group Gotcha; that makes sense considering how users are handled. > There's some social stuff if you find later that you want it. Fossil development moved from a more traditional mailing list to a self-hosted forum a while ago, but it isn't enabled by default. That all sounds reasonable (this + the tech notes you mention next). I generalized a bit too wide when I said "social stuff". I was thinking more along the social media angle (GitHub stars, follows, etc.); but with the way it sounds, that wouldn't make sense given the user model anyway! I currently run a Forgejo instance for a small team, and I can disable some of those features, but it just feels a bit messy with so many UI elements that don't have a purpose. > If you stick just to HTML and CSS, you should be fine. The functionality is pretty spartan. I think I'll have to try it out to see what is possible on this front! > This is governed by the capabilities assigned to a user. [...] Between this and login groups, it actually looks quite reasonable to manage a set of repositories in the way I'd like! I really dig everything being so tightly coupled to a given project, actually. Makes me a bit bummed I never gave Fossil a look all these years. > 2: Funnily enough, it shares the same pain as administering Plan 9's fossil(4) fileserver. Reading that over, I can see how that requires some due diligence. I already foresee the inevitable "why weren't the changes propagated to the other repositories?" moment. I think this will be my weekend project!