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: Wed, 02 Oct 2024 22:41:40 +0300

> Date: Wed, 2 Oct 2024 21:57:48 +0300
> Cc: sbaugh <at> catern.com, 62731 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> > And relying on b/ being an existing directory can cause
> > false positives.  How about relying on the "--git" part in the
> > "diff --git" header instead, and in the Git case _always_ removing one
> > leading directory?
> 
> I guess that's an option too.
> 
> > (And if this also happens with Hg, include that in
> > the test as well.)
> 
> 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.

> > 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.

> 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.

Previous Next

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