Re: Git for games working group

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 15, 2018, 16:40 UTC
Message-ID: <20180915164052.GA88932@syl>
In-Reply-To: <CA+AhR6fH4=VbuMPasbaH9u52Y=tgJJzhgxosPOb3819ivCVJOg@mail.gmail.com>

On Fri, Sep 14, 2018 at 02:09:12PM -0700, John Austin wrote:

> I've been working myself on strategies for handling binary conflicts,
> and particularly how to do it in a git-friendly way (ie. avoiding as
> much centralization as possible and playing into the commit/branching
> model of git).

Git LFS handles conflict resolution and merging over binary files with two primary mechanisms: (1) file locking, and (2) use of a merge-tool.

  1. is the most "non-Git-friendly" solution, since it requires the use
     of a centralized Git LFS server (to be run alongside your remote
     repository) and that every clone phones home to make sure that they
     are OK to acquire a lock.

     The workflow that we expect is that users will run 'git lfs lock
     /path/to/file' any time they want to make a change to an
     unmeregeable file, and that this call first checks to make sure
     that they are the only person who would hold the lock.

     We also periodically "sync" the state of locks locally with those
     on the remote, namely during the post-merge, post-commit, and
     post-checkout hook(s).

     Users are expected to perform the 'git lfs unlock /path/to/file'
     anytime they "merge" their changes back into master, but the
     thought is that servers could be taught to automatically do this
     upon the remote detecting the merge.

  2. is a more it-friendly approach, i.e., that the 'git mergetool'
     builtin does work with files tracked under Git LFS, i.e., that both
     sides of the merge are filtered so that the mergetool can resolve
     the changes in the large files instead of the textual pointers.

> I've got to a loose design that I like, but it'd be good to get some
> feedback, as well as hearing what other game devs would want in a
> binary conflict system.

Please do share, and I would be happy to provide feedback (and make proposals to integrate favorable parts of your ideas into Git LFS).

Thanks, Taylor