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

[Lars Ingebrigtsen]

Robert Pluim <rpluim@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