I shed a tear as I remembered the pain of doing that with SVN

Microsoft had a bunch of solutions to handle their massive Windows repo: VFS for Git (GVFS), Scalar, and now it has a bunch of MS specific patches on top of the official git client, but apparently that one is also not required any more as partial clone is now supported on azure as well (which is another such implementation from Microsoft employees that made it to both GitHub and upstream git).

So yeah, solved problem thanks to Microsoft. Solved multiple times in fact, and because it's Microsoft, only not all had Linux installers: https://github.com/microsoft/scalar/issues/323#issuecomment-...

https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...

https://devblogs.microsoft.com/devops/introducing-scalar/

https://github.com/microsoft/git

https://devblogs.microsoft.com/devops/git-partial-clone-now-...

Thanks!

> Add to that the necessity for less-technical people (artists, designers, VFX, audio, etc) to use it

How is that solved with Git?

Maybe they just need to follow carefully written instructions created by more technical people?

When has that ever worked? And why does this count as a solution rather than a poor workaround for you?

What has ever worked, reading and following manuals? Like, forever? Stop pretending there's a simple solution. People just need to use their brains. Both people who write those manuals and those who read them.

There literally already is a simpler solution for non-technical people, it’s called Perforce and tons of game studios use it

But I’m sure you’re smarter than the whole industry so you probably know better

Hey smart man, this is a thread about git, not perforce. Just fyi.

Since forever? It's not like people are born with an innate knowledge of how any software works.

Manuals/guides/tutorials are the most scalable way to teach people how to do literally anything.

>Most of this was built by Microsoft to work on Windows with git.

Hacking git into something it is not does not qualify as learning to cope with git in my book.

Apparently git does not solve all problems and there is indeed value in exploring other options and building new systems that fill other niches.

umm. it's still git. Git is basically content-addressable storage with a couple of layers on top (heads/tags/trees) which is itself content-addressable storage. If you can offload that storage to a remote, you still have git... and can use git as you've always used git. The tricky part is making it feel like the storage is local and your own, instead of shared.

You only need this when, well, you need it. You can go a surprisingly long way (nearly a decade of daily commits by hundreds of programmers) and stick to vanilla git.