GNU bug report logs - #43297
27.1; corrupts patch when diff-update-on-the-fly is set to nil

Previous Next

Full log

Message #19 received at 43297 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Mark H Weaver <mhw <at> netris.org>, 43297 <at> debbugs.gnu.org
Subject: Re: bug#43297: 27.1; corrupts patch when diff-update-on-the-fly is
 set to nil
Date: Fri, 16 Oct 2020 16:47:49 +0200

Robert Pluim <rpluim <at> gmail.com> writes:

> Search backwards from end-of-buffer for "-- " and then narrow the
> buffer from (point-min) to there? Kind of hacky I guess, but otherwise
> you'll have to complicate the pcase.

I'm fine with complicating the pcase, but I don't really know how to
resolve this.  A line like "-- " may really be a legitimate diff line,
or it may be a signature.

If we parsed the file from the top, and we assumed that nobody had
edited the patch, then we could see whether the "-- " was outside the
patch hunk or not, but the point of the function is to fix up the hunk
headers, so that's not really an option, either.

So I don't quite know whether this can even be fixed...  and it's a real
problem, since git format-patch puts a "--" signature at the end, it
looks like.

But...  we could, as a heuristic, guess that if the very first line we
see that could belong to a patch looks like "-- ?", then we ignore it.

That's probably better than what we have today, where patch destruction
is assured.  With a hack like that, we'd destroy patches rarely, I
think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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