From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: sbaugh@catern.com, 62731@debbugs.gnu.org
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 [thread overview]
Message-ID: <86wmipzqis.fsf@gnu.org> (raw)
In-Reply-To: <92fc2d1f-492d-4d42-914f-b6a4cd712306@gutov.dev> (message from Dmitry Gutov on Wed, 2 Oct 2024 22:48:27 +0300)
> Date: Wed, 2 Oct 2024 22:48:27 +0300
> Cc: sbaugh@catern.com, 62731@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> 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.
next prev parent reply other threads:[~2024-10-03 5:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-09 1:14 bug#62731: 29.0.60; diff-apply-hunk doesn't work for creating new files sbaugh
2024-10-02 0:41 ` Dmitry Gutov
2024-10-02 6:58 ` Eli Zaretskii
2024-10-02 18:57 ` Dmitry Gutov
2024-10-02 19:41 ` Eli Zaretskii
2024-10-02 19:48 ` Dmitry Gutov
2024-10-03 5:47 ` Eli Zaretskii [this message]
2024-10-04 1:14 ` Dmitry Gutov
2024-10-07 23:28 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86wmipzqis.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=62731@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=sbaugh@catern.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).