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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 07 Feb 2019 17:50:30 +0200

Stefan, Dmitry, can I have your attention please?

I think there's a real mess regarding encoding and decoding stuff in
vc-find-revision and its backend implementations.  For some reason,
several backend implementations bind both coding-system-for-read and
coding-system-for-write to no-conversion when they invoke the VCS to
produce a file at a certain revision.  Here's an example from
vc-git.el:

  (defun vc-git-find-revision (file rev buffer)
    (let* (process-file-side-effects
	   (coding-system-for-read 'binary)
	   (coding-system-for-write 'binary)
	   (fullname
	    (let ((fn (vc-git--run-command-string
		       file "ls-files" "-z" "--full-name" "--")))
	      ;; ls-files does not return anything when looking for a
	      ;; revision of a file that has been renamed or removed.
	      (if (string= fn "")
		  (file-relative-name file (vc-git-root default-directory))
		(substring fn 0 -1)))))
      (vc-git-command
       buffer 0
       nil
       "cat-file" "blob" (concat (if rev rev "HEAD") ":" fullname))))

Any idea why it insists on disabling code-conversions?

More generally, the find-revision method is documented as

  Fetch revision REV of file FILE and put it into BUFFER.

There's nothing here that hints that the resulting buffer will not
look like any visited file, i.e. after decoding.  Am I missing
something?

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.

It is my impression that one of the backends did these bindings for
some reason, and then others simply copy-pasted from it.

I'd like to fix this mess, if possible.

Thanks in advance for any insights.