bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename

[Eli Zaretskii]

> Cc: 34350@debbugs.gnu.org, vincent.belaiche@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 8 Feb 2019 20:25:35 +0300
> 
> On 07.02.2019 18:50, Eli Zaretskii wrote:
> 
> > Any idea why it insists on disabling code-conversions?
> 
> This was well before my time, and the only people I remember messing 
> with these variables anywhere in VC ever since are you (for 
> Windows-related fixes) and Michael. So this might require some digging 
> with vc-annotate.

How is vc-annotate relevant to vc-git-find-revision and the issue at
hand?  The last thing vc-find-revision does is to visit the file
written by the back-end, and it visits it normally, with
find-file-noselect, which decodes the contents as usual.  The problems
I see are with forcing no-conversion in the intermediate operations in
the back-end, where it extracts the specified version to a buffer.

> Also note that this affects two commands: one that returns the file 
> name, and another, its contents. I'm not sure what encoding 'git 
> cat-file blob' outputs in.

We already have in vc-git a variable that holds that encoding (UTF-8
by default).

> > In addition to producing undecoded buffer, these bindings have the
> > adverse effect of forcing Emacs not to encode command-line arguments
> > we pass to the VCS, which is the immediate cause for the current bug.
> 
> The adverse effect sounds like a separate bug.

It's not a bug, it's a documented feature.  coding-system-for-write
affects both I/O from and to a subprocess and the encoding of the
command-line arguments we pass to that subprocess.  That's why we
should be extra-careful when binding coding-system-for-write around
invocations of other programs.