Re: Git for games working group

From: Taylor Blau <me@ttaylorr.com>
Date: Sep 17, 2018, 13:48 UTC
Message-ID: <20180917134802.GE71477@syl>
In-Reply-To: <20180916075604.GB18517@gmail.com>

On Sun, Sep 16, 2018 at 12:56:04AM -0700, David Aguilar wrote:

Show 14 quoted lines

> Combining changes is inherently file-format specific, and I suspect
> that native authoring tools are best used in those scenarios.
> Maybe LFS can help deal with binary conflicts by having short and sweet
> ways to grab the "base", "their" and "our" versions of the conflict
> files.
>
> Example:
>
> 	git lfs checkout --theirs --to theirs.wav conflict.wav
> 	git lfs checkout --ours --to ours.wav conflict.wav
> 	git lfs checkout --base --to base.wav conflict.wav
>
> Then the user can use {ours,theirs,base}.wav to produce the
> resolved result using their usual authoring tools.

That's a good idea, and I think that it's sensible that we teach Git LFS how to do it. I've opened an issue to that effect in our tracker:

  https://github.com/git-lfs/git-lfs/issues/3258

Show 5 quoted lines

> One thought that comes to mind is diffing -- I imagine that we
> might want to use different diff tools depending on the file format.
> Currently git-difftool uses a single tool for all files, but it seems
> like being able to use different tools, based on the file type, could
> be helpful.

We have had some internal discussion about this. I think that we had landed on something similar to:

  1. Teach .gitattributes a new mergetool= attribute, which would
     specify a reference to a mergetool driver, and

  2. Teach .gitconfig about a way to store meregtool drivers, similar to
     how we name filters today.

Upon my re-reading of this proposal, it was suggested that we implement this in terms of 'git lfs mergetool', but I don't see why this wouldn't be a good fit for Git in general.

Thanks, Taylor