GNU bug report logs - #72556
29.1.90; vc-diff does not undo hunk in end of source file

Previous Next

Full log

View this message in rfc822 format

From: Tomas Nordin <tomasn <at> posteo.net>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 72556 <at> debbugs.gnu.org
Subject: bug#72556: 29.1.90; vc-diff does not undo hunk in end of source file
Date: Sat, 01 Mar 2025 14:28:04 +0000

[Message part 1 (text/plain, inline)]

Juri Linkov <juri <at> linkov.net> writes:

>> Juri and Dmitry, any comments or suggestions?
>
> I don't know why it fails at the end, so I tried to debug 'diff-apply-hunk',
> and found that the problem is in these lines of 'diff-find-source-location':
>
>     ;; FIXME: Check for case where both OLD and NEW are found.
>     (pos (or (diff-find-text (car old))
>
> When the hunk is at the beginning/end of the diff buffer,
> then it misses the top/bottom part of the context,
> so 'diff-find-text' wrongly matches it because it fails
> to see any changes in it due to insufficient context,
> and returns switched=nil.

Here is some notes from a bug-hunt (mabye a glorified variant of what
you are already saying Juri).  Perspective is from
'diff-find-source-location' in diff-mode.el

The call (diff-find-text (car old)):
    OLD is text derived from hunk representing text in the source file
    before the edits. => nil if not found in the source file

The call (diff-find-text (car new)):
    NEW is text derived from hunk representing text in the source file
    after the edits. => nil if not found in the source file

Assumptions made on result from applying 'diff-find-text' on

NEW: if non-nil, hunk is already applied
OLD: if non-nil, hunk is not applied

When the edited line(s) have context only above or below itself in the
hunk, the application of diff-find-text on OLD will always yield
non-nil, because OLD is then always found in the source file.

The application of diff-find-text on NEW shouldn't have similar
problems.

There is a comment requesting a fix for when both OLD and NEW are
found.  Maybe this was the case concerned.

The variable SWITCHED, then, should be non-nil when hunk is already
applied, and is a prerequisite for the DWIM behavior to work (the
bug).  It is not set to t when 'diff-find-text' is applied on OLD (the
first or:ed attempt), which returns non-nil.

The attached patch of diff-mode.el makes the assumption that hunk is
already applied when both OLD and NEW yields non-nil, and checks if
this is the case as the first or:ed attempt.  Optimistically assumes
that this was the requested FIXME and so removes the FIXME comment.

Dmitri had concerns about drawbacks when splitting a hunk.  I don't have
successful experience of that operation.  Can Dmitri maybe check so that
this patch don't produce such drawbacks?

[0001-Fix-detection-of-hunk-already-applied.patch (text/x-diff, attachment)]

Previous Next

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