From: Michael Orlitzky <michael@orlitzky.com>
To: bug-gnu-emacs@gnu.org
Subject: bug#5352: diff-jump-to-old-file inverts hunk application as well
Date: Sun, 10 Jan 2010 23:39:20 -0500 [thread overview]
Message-ID: <4B4AAB78.7030102@orlitzky.com> (raw)
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.
next reply other threads:[~2010-01-11 4:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-11 4:39 Michael Orlitzky [this message]
2022-05-09 14:32 ` bug#5352: diff-jump-to-old-file inverts hunk application as well Lars Ingebrigtsen
2022-05-09 16:18 ` Michael Orlitzky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B4AAB78.7030102@orlitzky.com \
--to=michael@orlitzky.com \
--cc=5352@debbugs.gnu.org \
--cc=bug-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.