bug#65049: Minor update to the repro steps

[Eli Zaretskii]

> Date: Fri, 25 Aug 2023 00:44:58 +0300
> From: Dmitry Gutov <dmitry@gutov.dev>
> Cc: juri@linkov.net, habamax@gmail.com, 65049@debbugs.gnu.org
> 
> On 25/08/2023 00:35, Dmitry Gutov wrote:
> > On 25/08/2023 00:06, Dmitry Gutov wrote:
> >>
> >>> But before I do, could you
> >>> please try the recipe here:
> >>>
> >>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65049#68
> >>>
> >>> but with the following change in step 4:
> >>>
> >>>    4. C-x RET f utf-8-dos RET
> >>>
> >>> That is, try the recipe on a Posix host with a file whose EOL format
> >>> is CRLF.  If that works without any changes in the current VC code, I
> >>> will be happy to make the first hunk Windows-specific.
> >>
> >> That works with the current emacs-29. Also tried with the patch 
> >> applied -- still works.
> > 
> > But here's a modification of the scenario that fails (again: both with 
> > and without the patch): replace step 9 with
> > 
> >    9. C-x v =
> > 
> > The non-root diff looks a little different to begin with: it doesn't 
> > show those ^M chars at the end of lines (whereas the result of 
> > vc-root-diff shows them). That is likely the reason: buffer set up in a 
> > different way.
> 
> Looks like it's this line:
> 
>        (coding-system-for-read
>         (if files (vc-coding-system-for-diff (car files)) 'undecided))
> 
> near the beginning of vc-diff-internal that creates the difference. 
> Commenting it out makes the scenario work with both 'C-x v =' and 'C-x v D'.

That code fragment is very old, so just removing it is scary, even if
only in master.

What if you change that fragment to say

         (coding-system-for-read
          (if files (vc-coding-system-for-diff (car files)) 'undecided-unix))

instead?  If that doesn't work, please tell to what value does
vc-diff-internal set coding-system-for-read in your case there, and I
will try to figure out what would needs to be done there.

(In general, I believe that using Git on Posix hosts with files that
have DOS EOLs could have such problems in other use cases, where diffs
are generated and then applied as patches.  We just don't know about
those cases because they are extremely rare in Real Life.)