Re: Git for games working group

[John Austin <john@astrangergravity.com>]

> There's also the nascent "don't fetch all the blobs" work-in-progress
> clone mode which might be of interest to you:
> https://blog.github.com/2018-09-10-highlights-from-git-2-19/#partial-clones

Yes! I've been pretty excited about this functionality. It drives a
lot of GVFS/VFS for Git under the hood. I think it's a great solution
to the repo-size issue.

> Is this just a reference to the advisory locking mode perforce/cvs
> etc. have or is there something else at play here?

Good catch. I actually phrased this precisely to avoid calling it
"File Locking".

An essential example would be a team of 5 audio designers working
together on the SFX for a game. If one designer wants to add a layer
of ambience to 40% of the .wav files, they have to coordinate with
everyone else on the project manually. Without coordination this
developer will clobber any changes made to these files while he worked
on them. File Locking is the way that Perforce manages this, where a
developer can exclusively block modifications on a set of files across
the entire team.

File locking is just one solution to the problem. It's also one that
doesn't play well with git's decentralized structure and branching
model. I would state the problem more generally:
Developers need some way to know, as early as possible, if modifying a
file will cause conflicts upstream.

Optionally this knowledge can block modifying the file directly (if
we're certain there's already a conflicting version of the file on a
different branch).

JA