From: Andreas Gruenbacher <agruen@suse.de>
To: git@vger.kernel.org
Subject: GNU patch: new alpha release
Date: Mon, 23 Mar 2009 00:49:56 +0100 [thread overview]
Message-ID: <200903230049.56549.agruen@suse.de> (raw)
Hello,
I am pleased to announce my first alpha release of GNU patch,
available by anonymouns FTP from:
ftp://alpha.gnu.org/gnu/patch/
The purpose of this release is to allow people to test changes which will
eventually end up in the next stable release.
The last release dates back to June 2004 with version 2.5.9. I would like to
thank Paul Eggert for his work on GNU patch, and for making his code
repository available for import. A new project has been created on Savannah
with the new code repository and the bug-patch@gnu.org mailing list archive:
http://savannah.gnu.org/projects/patch
A lot of things have accumulated since version 2.5.9. I am in the process of
reviewing more bug reports to bug-gnu-utils@gnu.org and bug-patch@gnu.org.
Meanwhile, several issues have already been addressed, and the following user
visible changes have been made:
* A regression test suite has been added ("make check").
* Unless a filename has been specified on the command line, look only
for filenames in the patch until one has been found. Start looking
for hunks only after that. This prevents patch from tripping over
garbage that isn't a patch. When conforming to POSIX, this behavior
is turned off and patch will ask for a filename when none is found.
* Reject more malformed normal format commands and check for trailing
garbage. Recognize ed commands without addresses.
* All reject files have file name headers, which allows to use them
as regular patches.
* When a patch file modifies the same file more than once, patch makes
sure it backs up the original version of the file, rather than any
intermediary versions.
* In the above situation, if there are rejects in more than one of those
patches, the rejects are appended to the same reject file (rather then
overwriting themselves).
* The -r option works correctly even there are rejects in more than one
file. Use the - argument to discard rejects.
* Rejected hunks come out in unified diff format if the input patch was of
that format, otherwise in ordinary context diff form. Use the
--reject-format option to enforce either "context" or "unified" format.
The "diff -p" (--show-c-function) output is preserved.
Changed lines in context format reject files are correctly indicated
with '!' markers as the format defines. Added and removed lines are
still marked with '+' and '-', respectively.
* The file permissions of reject files are no longer set to match the files
they modify. Instead, they retain the default permissions. This is
consistent with reject files to which rejects of multiple files may be
written (-r option).
* The --binary option disables the heuristic for stripping CRs from
line endings in patches. This allows to preserve CRs even in mangled
patches, or in patches generated without the --binary option on non-POSIX
systems.
More fixes and improvements are pending. Please see the project's bug tracker
for a (so far incomplete) list of known issues before reporting those things
again on the mailing list.
Please email bugs or suggestions to <bug-patch@gnu.org>.
Thanks,
Andreas
reply other threads:[~2009-03-22 23:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=200903230049.56549.agruen@suse.de \
--to=agruen@suse.de \
--cc=git@vger.kernel.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).