GNU bug report logs - #5352
diff-jump-to-old-file inverts hunk application as well

Previous Next

Package: emacs;

Reported by: Michael Orlitzky <michael <at> orlitzky.com>

Date: Mon, 11 Jan 2010 06:34:01 UTC

Severity: normal

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5352 in the body.
You can then email your comments to 5352 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#5352; Package emacs. (Mon, 11 Jan 2010 06:34:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Orlitzky <michael <at> orlitzky.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 11 Jan 2010 06:34:01 GMT) Full text and rfc822 format available.

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

From: Michael Orlitzky <michael <at> orlitzky.com>
To: bug-gnu-emacs <at> gnu.org
Subject: diff-jump-to-old-file inverts hunk application as well
Date: Sun, 10 Jan 2010 23:39:20 -0500
The custom diff-jump-to-old-file causes a reversal of the traditional
diff/patch behavior present in Emacs <= 22. From diff-mode.el, it seems
sort of intentional that this is the case; nevertheless, the new
behavior does not strike me as useful. From diff-mode.el:

(defun diff-apply-hunk (&optional reverse)
  "Apply the current hunk to the source file and go to the next.
  By default, the new source file is patched, but if the variable
  `diff-jump-to-old-file' is non-nil, then the old source file is
  patched instead (some commands, such as `diff-goto-source' can change
  the value of this variable when given an appropriate prefix argument).

Why should the default be to patch the new file, which is by definition
already patched? Take for example,

  gantu ~ $ cat new.txt
  Line 1
  Line 2
  Line 3
  Line 4
  gantu ~ $ cat source.txt
  Line 1
  Line 2
  Line 4
  gantu ~ $ diff -c source.txt new.txt > test.patch
  gantu ~ $ emacs -nw test.patch

(The diff -c accomplishes the same thing as M-x diff would within
Emacs). In this case, when the patch is opened, it is expected that M-x
diff-apply-hunk will patch the source (old) file to the new. That is, it
should add "Line 3" to the third line of the source file. This is how
Emacs <= 22 worked.

With v23, the new behavior is that M-x diff-apply-hunk will attempt to
apply the hunk to new.txt which, of course, already contains that line.
Even if one performs the diff within Emacs and explicitly chooses the
source/new files, the default behavior is to attempt to re-patch the new
file.







Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#5352; Package emacs. (Mon, 09 May 2022 14:33:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Orlitzky <michael <at> orlitzky.com>
Cc: 5352 <at> debbugs.gnu.org
Subject: Re: bug#5352: diff-jump-to-old-file inverts hunk application as well
Date: Mon, 09 May 2022 16:32:11 +0200
Michael Orlitzky <michael <at> orlitzky.com> writes:

> The custom diff-jump-to-old-file causes a reversal of the traditional
> diff/patch behavior present in Emacs <= 22. From diff-mode.el, it seems
> sort of intentional that this is the case; nevertheless, the new
> behavior does not strike me as useful. From diff-mode.el:
>
> (defun diff-apply-hunk (&optional reverse)
>   "Apply the current hunk to the source file and go to the next.
>   By default, the new source file is patched, but if the variable
>   `diff-jump-to-old-file' is non-nil, then the old source file is
>   patched instead (some commands, such as `diff-goto-source' can change
>   the value of this variable when given an appropriate prefix argument).
>
> Why should the default be to patch the new file, which is by definition
> already patched? Take for example,

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I think the logic here is when you have a diff that's been partially
applied, so that the "new" file isn't literally the one you've already
applied the patch to.

In that case, you usually want to apply the hunk to the new file, and
not the old one.

In any case, the current behaviour has been in place for a decade, so I
think it's too late to change it now (because that would break things
for people that's used to the direction it works in now).

So I'm closing this bug report.

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




bug closed, send any further explanations to 5352 <at> debbugs.gnu.org and Michael Orlitzky <michael <at> orlitzky.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 09 May 2022 14:33:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#5352; Package emacs. (Mon, 09 May 2022 16:19:01 GMT) Full text and rfc822 format available.

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

From: Michael Orlitzky <michael <at> orlitzky.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 5352 <at> debbugs.gnu.org
Subject: Re: bug#5352: diff-jump-to-old-file inverts hunk application as well
Date: Mon, 09 May 2022 12:18:04 -0400
On Mon, 2022-05-09 at 16:32 +0200, Lars Ingebrigtsen wrote:
> 
> So I'm closing this bug report.
> 

This seems to be working like I expect it to now, so maybe the issue
was elsewhere and has been fixed in the meantime.





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 07 Jun 2022 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 8 days ago.

Previous Next


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