On Sun, Sep 16, 2018 at 12:56:04AM -0700, David Aguilar wrote:
> 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
> 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
