Re: ediff merge wrapper

[Eliza Velasquez]

I replied with more details about how it works, but it seems I
accidentally sent them in a private email to Stefan. Sorry about that,
I'm not quite used to mailing lists. I'll copy what I wrote here.

Google's ediff_merge tool is invoked like:

ediff_merge /path/to/base_file /path/to/ancestor /path/to/file-a
/path/to/file-b /path/to/output-file

This command blocks until the merge operation is complete, i.e. when
the user quits ediff.

Upon further investigation of its source code, it seems that the need
for this tool may be obsoleted if this bug were to be fixed instead:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25547. Most of the
purpose of this tool seems to be a workaround for this behavior, and
it could probably be replaced with a call to `emacsclient -c -e
'(ediff-merge-with-ancestor "$a" "$b" "$ancestor" nil "$output")'` if
it were fixed.

Stefan and I had some additional discussion on the bug thread.

On Tue, Nov 3, 2020 at 8:47 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Eliza Velasquez <exv@google.com>
> > Date: Mon, 2 Nov 2020 12:01:33 -0800
> >
> > Internally at Google, we have a wrapper performing an ediff merge with
> > emacs/emacsclient which blocks until the merge operation has
> > completed. It automatically handles edge cases such as creating a new
> > frame over ssh in tty mode or being invoked as an emacs subprocess. I
> > think it would be really useful to upstream a tool like this, given
> > that using emacs as a merge tool that can be invoked by software such
> > as mercurial or perforce can be very fiddly or have unexpected
> > behavior.
>
> Can you describe the use of this tool in more detail, and what
> enhancements it implements beyond what emacsclient provides?  I don't
> think I understand that from your short description.
>
> Thanks.