Subject: bug#62731: 29.0.60; diff-apply-hunk doesn't work for creating new files

From: Eli Zaretskii <[email-masked]>
Date: Wed, 02 Oct 2024 22:41:40 +0300

> Date: Wed, 2 Oct 2024 21:57:48 +0300
> Cc: [email-masked], [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 
> > 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.