GNU bug report logs - #62731
29.0.60; diff-apply-hunk doesn't work for creating new files

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> catern.com, 62731 <at> 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

> Date: Wed, 2 Oct 2024 22:48:27 +0300
> Cc: sbaugh <at> catern.com, 62731 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.