Certainly meant to be more of a teaser. We’ll get there.

It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say. But there’s just a lot of stuff that’s already working in existing systems that just hasn’t been productized because those companies aren’t trying to get into the version control business.

If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines. We think that workflow is very valuable for people.

We certainly know that people will want to know more details before they buy, and have shared stuff with prospective customers during the POC process. We’ll be more generally open about it over time.

> It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say.

If I can ever get around to writing about it or polishing up what I have enough that I feel comfortable with someone else looking at it, I'll poke you directly about some of what I've been working on over on the Fossil side of things.

> If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines.

Oh, hey, yeah. I'm not first-hand familiar with that tooling (I've never been at Google), but there's a similar(-ish) workflow I've been kind of missing from Plan 9, so I've been hammering on that a little. Something like `m1 client connect $remote_url --name $client_name` and `m1 workspace bind M: --client_name $client_name --name $workspace_name`, which is a slightly more obtuse take on running `9fs` to authenticate and bind the sources server into the current namespace.

I've found that, at the time of a client connecting, there's a lot of value for me in having, like, the last however many commit manifests and seldom much else as far as file data goes. I can pull down the raw blocks containing that data on demand, and at least for now, commit manifests contain a complete enumeration of what's in the file tree at that commit. That's enough for me to rehydrate a browsable filesystem projection of the repository before I decide that I need to mirror blocks locally.