robwayne

I feel like Neuro-sama is essentially already that, but for the Twitch / YT crowd instead of television. It's trivial to train a model to maximize engagement (as one can see gestures broadly), so I'm sure if we can get robots looking nice and human, we'll have Futurama's All My Circuits in no time.

Though I guess there was a token human on that show, so maybe you're right!

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!

It doesn't actually use it, this is just referencing it in the dependency graph (Cargo.lock). bs58 is an optional (feature-gated) transitive dependency of another crate, which is never referenced at all in the top-level crate. The build.rs doesn't run or anything.

I believe there's (several) open issues about changing this behavior of the lock file, but I have moved on from Rust so don't know the status of things.

That said, this is confusing behavior. I remember I first noticed it when a bunch of crates were showing up in my lock file for every OS under the sun, even though I was specifically using a "wayland" (linux-only) feature.

Not to defend Rust's crazy culture of dependencies, mind you.

I've sorta overlooked Fossil a lot (mostly because it's not git...), but just browsing some instances on chisel and the fossil homepage has me intrigued.

If you'll entertain me for a moment...

My dream "forge" would just be nice-looking frontend for displaying repos on the web, a public issue tracker (with per-issue permissions), a public way to submit issues, and essentially a single canonical root for repositories that users on the team work on. I don't want individual user repos or pages, organizations, or any social stuff. I definitely don't want open registration.

It really looks like fossil is actually what I've always wanted.

How limiting is the custom theme support? It looks like you can just straight up write your own HTML/CSS for everything. If I really want a custom design, will I be disappointed in the long run?

Also, it looks like it follows that user model I want, where it's "repositories with users" instead of "users with repositories". Is that correct?

And here I was trying to hype myself up to write my own git web frontend.