Microsoft and GitHub team up to take Git virtual file system to macOS, Linux

Re:Microsoft and GitHub team up to take Git virtual file sys... by vvanders on Friday November 17, 2017 @04:46PM (#15726250)

Git LFS doesn't solve the gamedev/large asset problem.

The issue is that these giant binary files cannot be merged. Because of this you need a locking mechanism(which SVN and Perforce both support).

Without that you have two people working on the same file and someone having to throw away work which makes for a very unhappy team.

DVCS is great but not every problem domain maps to it.

[ Parent | on HN ]

Re:Microsoft and GitHub team up to take Git virtual file sys... by evanosaurus on Saturday November 18, 2017 @09:02AM (#15728947)

This is why we’re mostly stuck in Perforce hell in the games industry.

[ Parent | on HN ]

Re:Microsoft and GitHub team up to take Git virtual file sys... by ethomson on Friday November 17, 2017 @05:01PM (#15726360)

git-lfs supports locking, beginning in 2.0.

[ Parent | on HN ]

Re:Microsoft and GitHub team up to take Git virtual file sys... by vvanders on Friday November 17, 2017 @05:11PM (#15726419)

Man, had to really dig to find that. Ctrl-F "lock" didn't hit anything on the landing page or main docs page.

Even then it looks like an implementation that misses the mark. Both Perforce and SVN mark "lockable" files as Read-Only on a sync of the local copy. It looks like all this does is prevent a push of the file which will be the same result as if someone merged it ahead of you.

Without that guard in place it makes it really easy to make a mistake and then have changes to a binary file that will collide. Having a checkout process as part of locking workflow is pretty much mandatory.

[edit]

Nevermind, I finally found this[1] that explains Git LFS does it correctly, kudos! Could do with some more detailed documentation since it looks partially implemented from the man pages.

[1] https://github.com/git-lfs/git-lfs/wiki/File-Locking

[ Parent | on HN ]