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
