From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#65049: Minor update to the repro steps Date: Wed, 23 Aug 2023 23:13:18 +0300 Message-ID: <35b50832-e9ca-9f57-fad6-68621d9b42e7@gutov.dev> References: <83y1iruky1.fsf@gnu.org> <83il9qom6k.fsf@gnu.org> <86v8dandhq.fsf@mail.linkov.net> <83bkf1woy3.fsf@gnu.org> <835y57tf23.fsf@gnu.org> <87edjvp6ev.fsf@gmail.com> <83350btdw8.fsf@gnu.org> <831qftspal.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38058"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: 65049@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii , Maxim Kim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 23 22:14:18 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qYuF7-0009eY-Hh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Aug 2023 22:14:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qYuEr-000482-Kj; Wed, 23 Aug 2023 16:14:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qYuEp-00047k-6Z for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 16:13:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qYuEo-0003ag-Uh for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 16:13:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qYuEs-0000qv-7B for bug-gnu-emacs@gnu.org; Wed, 23 Aug 2023 16:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 20:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65049 X-GNU-PR-Package: emacs Original-Received: via spool by 65049-submit@debbugs.gnu.org id=B65049.16928216143234 (code B ref 65049); Wed, 23 Aug 2023 20:14:02 +0000 Original-Received: (at 65049) by debbugs.gnu.org; 23 Aug 2023 20:13:34 +0000 Original-Received: from localhost ([127.0.0.1]:35240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYuEP-0000q6-Qi for submit@debbugs.gnu.org; Wed, 23 Aug 2023 16:13:34 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:41649) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYuEM-0000pp-LD for 65049@debbugs.gnu.org; Wed, 23 Aug 2023 16:13:32 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E65EE5C01CE; Wed, 23 Aug 2023 16:13:21 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 23 Aug 2023 16:13:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1692821601; x=1692908001; bh=YsuBMkVuIvNOZqjSOxGg3M7UMzX+UHAkZpY PGOOtCKE=; b=HHbkx42jY7/e14fzB7sMJhViSlfce/ucyTNFUAJm0JFn9gjwfJ1 dbbD2IE6EYddS1dhUmNT+lme7EpwEWJbjxr4pMEqrFebvUVWwx4KCJFfNcqy2J1l NXg/8xsoYWb4NzAsy1E7FVwCBsM9ralvMKNR3C4vgcgpVzWgBcV6KcwLg3NFf1Hk HicIG9G4NzEYmLdJcFgDP2okm1pSYXhjrnEy1FId/dqPApxcSCfhdASqQ3dcVZjf qST1vJOzu/aed7pZR2/gc4M7vo17Hkz8acICwPo6TCe0oidNc0HLdjAR5x/AJIYi L7SA8Hd1FH3ReyrWJYYLXhEwsBUJjAUD+sQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692821601; x=1692908001; bh=YsuBMkVuIvNOZqjSOxGg3M7UMzX+UHAkZpY PGOOtCKE=; b=0ZW34xwDzRY2bP2TvJiHtk4wGPHuUQZvFzB8GTuBIlZ31Yy0vDx bmORPycDTy5kyrR6T+nU3LH4TBmBOnsXaPM+WzhFy0ZVzzmgPMzb9eA3SshBQfrX iiXzn2yI3ylWp4vhevxfLlnApOQg9X36YH+fjU3hhb20oBWN17lHvmORjq9W+M6y N9IkDwkDhAKRO8/2Q2sMkuCYb+a8V++MU9T1FT2+aGWCMH3RlkgzcbQPSMRBkoqE xyJmGRUz+Abee5+iLIJTmNn7lx57UcJbIFJ3Ms1dZigs2tSRFPRqEeGR7OlG2UTS PWTN5Wnt9kxuA+xPEsZXOPH4erKtjZQg/lQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddvgedgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Aug 2023 16:13:20 -0400 (EDT) Content-Language: en-US In-Reply-To: <831qftspal.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268271 Archived-At: On 23/08/2023 19:21, Eli Zaretskii wrote: >> From: Maxim Kim >> Cc: juri@linkov.net, 65049@debbugs.gnu.org >> Date: Wed, 23 Aug 2023 14:28:10 +1000 >> >> Eli Zaretskii writes: >> >> So, it works for the repo with files having windows CRLF. >> And doesn't work if the file has EOL type: LF. > > Thanks, this finally allowed me to nail the sucker. The fix is a bit > more complex than I thought, because this bug has two parts: one of > them in "C-x v D", the other in vc-git-checkin. The patch is below; > please give it a try with all your real-life use cases. > > Dmitry, do you see any problems with installing this on the release > branch? Or do you prefer to keep it on master for a while, and then > backport if no one complains? It doesn't look "obviously correct" to me, and I'm no pro in the coding system department. If the patch shouldn't affect non-Windows systems (which seems to be clear for the second hunk, but not for the first one), I'd say we test (and ask to test) several orthogonal scenarios: when the system is in the standard language environment, and when it's in the "unixy" one. And the same regarding the repository. If everything's okay, maybe it's good for emacs-29. It will have a few months to stabilize, right? Just as long as the patch goes into master too (that's where the bulk of the stabilization will happen, since we have generally switched to that branch now for daily use). > diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el > index 7ae763d..218696c 100644 > --- a/lisp/vc/vc-git.el > +++ b/lisp/vc/vc-git.el > @@ -1051,7 +1051,15 @@ vc-git-checkin > (user-error "Index not empty")) > (setq pos (point)))))) > (unless (string-empty-p vc-git-patch-string) > - (let ((patch-file (make-nearby-temp-file "git-patch"))) > + (let ((patch-file (make-nearby-temp-file "git-patch")) > + ;; Temporarily countermand the let-binding at the > + ;; beginning of this function. > + (coding-system-for-write > + (coding-system-change-eol-conversion > + ;; On DOS/Windows, it is important for the patch file > + ;; to have the Unix EOL format, because Git expects > + ;; that, even on Windows. > + (or pcsw vc-git-commits-coding-system) 'unix))) Any chance this change could negatively affect non-Windows systems? Is it a given that the 'unix' line endings are always used there? > (with-temp-file patch-file > (insert vc-git-patch-string)) > (unwind-protect > diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el > index 410fe5c..4e008de 100644 > --- a/lisp/vc/vc.el > +++ b/lisp/vc/vc.el > @@ -1917,8 +1917,12 @@ vc-diff-internal > (generate-new-buffer-name " *vc-diff-clone*") nil)))) > ;; On MS-Windows and MS-DOS, Diff is likely to produce DOS-style > ;; EOLs, which will look ugly if (car files) happens to have Unix > - ;; EOLs. > - (if (memq system-type '(windows-nt ms-dos)) > + ;; EOLs. But for Git, we must force Unix EOLs in the diffs, since > + ;; Git always produces Unix EOLs in the parts that didn't come > + ;; from the file, and wants to see any CR characters when applying > + ;; patches. > + (if (and (memq system-type '(windows-nt ms-dos)) > + (not (eq (vc-deduce-backend) 'Git))) > (setq coding-system-for-read > (coding-system-change-eol-conversion coding-system-for-read > 'dos))) :thumbsup: (All the coding system juggling in these files is already too scary for my taste, but I don't have any better suggestions.)