From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62731: 29.0.60; diff-apply-hunk doesn't work for creating new files Date: Thu, 03 Oct 2024 08:47:39 +0300 Message-ID: <86wmipzqis.fsf@gnu.org> References: <87jzyln9g0.fsf@catern.com> <86ldz70z4i.fsf@gnu.org> <36712130-53f5-4515-a887-d8df3175b271@gutov.dev> <86zfnmz40b.fsf@gnu.org> <92fc2d1f-492d-4d42-914f-b6a4cd712306@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23083"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@catern.com, 62731@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 03 07:48:22 2024 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 1swEhJ-0005u0-NU for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Oct 2024 07:48:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swEh4-0003zQ-VF; Thu, 03 Oct 2024 01:48:07 -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 1swEh0-0003wt-Q7 for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 01:48:03 -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 1swEgz-00082s-6Q for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 01:48:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=jLeXOQvWnMOfurstmGHLcsttbPr8zM7rZNd/PLDM4iI=; b=EbiTG2DonmFTRVZdJ4uC1nTjV9+t4wf3w0UbhG0MxvlsFuoxVx4hOwo0W1Lijmmk9p5TP7kxO8BuOKFuWtMLhm6OLkfXg1O+8iO/VFwNTm6FM/Y6sZrIZWtQPKnFEphXr4lAFFuKGbeNuHFS6usvXvsTV70UtZNAaDHpKvpbJQbiFDRFQMHy7ME6GIjGhcAzNxBb+EKk/dPaeJ1lzttynSAZnwKi+D47CkhBgrEF5wBEbVlzBuOvfVLB2Kpm8EyOBINcztrVZzuL1pGV3btF22XHCEwrJY5TZ+wR7YmP4z5MRUscvFFM446f8Z1utyyxZNOGf48FcFcDoSX1X7IIlg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swEgz-0004Yw-Uk for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 01:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Oct 2024 05:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62731 X-GNU-PR-Package: emacs Original-Received: via spool by 62731-submit@debbugs.gnu.org id=B62731.172793447217515 (code B ref 62731); Thu, 03 Oct 2024 05:48:01 +0000 Original-Received: (at 62731) by debbugs.gnu.org; 3 Oct 2024 05:47:52 +0000 Original-Received: from localhost ([127.0.0.1]:59728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swEgq-0004YR-1s for submit@debbugs.gnu.org; Thu, 03 Oct 2024 01:47:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swEgo-0004YE-Ix for 62731@debbugs.gnu.org; Thu, 03 Oct 2024 01:47:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swEgh-00081z-HT; Thu, 03 Oct 2024 01:47:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jLeXOQvWnMOfurstmGHLcsttbPr8zM7rZNd/PLDM4iI=; b=Nv15IxvWEqGk pDyyz6eneSpPuV91t65gjhOIG6qp6wvhKmrLkobp1KtitU4GyL+Y+s8OVhETq7jJipZFv3gVN7jvn jVtGbKyx4HpYhs9r5JKBOkWJk4EjEfuzmk+nTQM1wtaaeD5iDhhg9nNhcbTbVbVLZziZMIddUFK5y G/j/+cys0xQoOz+r3F/tgQtizNRSXWVdsG7kPR80mTb76zPTF4d2Mqm1y5//YS5gUcouw7drMvAao L65Lyo9Da7J0ZO116fpSpdxKrH+1SZ8Xr5vF3esKLfVTmpbE+wONic7qlK5hAhbSktnRB2f7XGIMU xPzEKkfM7AY4FSa7Ysoi8g==; In-Reply-To: <92fc2d1f-492d-4d42-914f-b6a4cd712306@gutov.dev> (message from Dmitry Gutov on Wed, 2 Oct 2024 22:48:27 +0300) 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:292880 Archived-At: > Date: Wed, 2 Oct 2024 22:48:27 +0300 > Cc: sbaugh@catern.com, 62731@debbugs.gnu.org > From: Dmitry Gutov > > On 02/10/2024 22:41, Eli Zaretskii wrote: > > >> With Hg, the format look like this: > >> > >> diff -r df0ef194120b -r 2039b18843da accessible/aom/AccessibleNode.cpp > >> > >> No mention of 'Hg', that is. Could we match "\`diff -r" and > > > > If Hg doesn't prepend fake leading directories, we don't need to be > > bothered by Hg. > > It does. A fuller example, with deletion: > > diff -r d045d1125783 -r 9396bae6ff0d CLOBBER.new > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/CLOBBER.new Fri Dec 15 20:37:14 2023 +0200 > @@ -0,0 +1,56 @@ OK, then does the presence of two -r options indicate Hg? Or is that not guaranteed, either? > >>> Also, what about the opposite case, when NEW is /dev/null? does that > >>> work correctly? > >> > >> Not currently or with the proposed patch. It could be fixed along > >> similar lines, but I'm not clear on the ideal behavior here. Delete the > >> "old" file and kill its buffer? And say that with 'message'? > > > > Something like that, yes. We could also delete the file silently. > > I'm concerned the user is going to wonder whether anything happened at > all, and checking is a non-trivial action. But if you think this is > fine, I guess it's something to try. Not sure I understand the problem. The user instructed us to apply diffs, one of which deletes a file. Why should we hesitate about deleting that file? > >> Deleting files is something that one can do manually, though, so solving > >> this seems lower priority. > > > > When you apply a large set of diffs in which one file is deleted, > > there's no easy way of knowing you should deleted that file. > > In the current version of code you will be asked midway through a file > (or right away, when using diff-apply-hunk) to specify a file name, > defaulting to /dev/null, and after you press C-g after seeing the odd > prompt the hunk won't be applied. So it's hard to miss, at least. Yes, but this is buggy behavior: there's no need to ask for a file name in this case. Emacs is just confused by the part of the diffs which delete a file because the code doesn't take that into account.