{"thread":{"id":"21608","subject":"GNU patch: new 2.6 release","startedAt":"2009-11-14T00:09:34Z","lastAt":"2009-11-15T14:02:20Z","messageCount":6,"participants":["Andreas Gruenbacher","Björn Gustavsson","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"127526","messageId":"200911140109.34202.agruen@suse.de","threadId":"21608","inReplyTo":null,"subject":"GNU patch: new 2.6 release","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2009-11-14T00:09:34Z","receivedAt":"2009-11-14T00:09:34Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"I am pleased to announce my first release of GNU patch,\navailable by anonymous FTP from:\n\n ftp://ftp.gnu.org/gnu/patch/\n\nThe last release dates back to June 2004 with version 2.5.9. A new Savannah \nproject has been created with the new code repository and the bug-patch \nmailing list archive at:\n\n http://savannah.gnu.org/projects/patch\n\nA lot of changes have accumulated since version 2.5.9. The following user \nvisible changes have been made:\n\n* A regression test suite has been added (\"make check\").\n\n* A --merge option has been added which will merge a patch file into\n the original files similar to merge(1). See the patch(1) manual page for\n documentation.\n\n* Unless a file name has been specified on the command line, look only\n for file names in the patch until one has been found. This prevents\n patch from tripping over garbage that isn't a patch. When conforming\n to POSIX, this behavior is turned off and patch will ask for a\n file name when none is found.\n\n* All reject files have file name headers now, which allows them to be used as\n regular patches.\n\n* When a patch file modifies the same file more than once, patch makes\n sure it backs up the original version of the file rather than any\n intermediary versions.\n\n* In the above situation, if there are rejects in more than one of those\n patches, they all go into the same reject file.\n\n* When the file to be patched is specified on the command line, all patches\n are applied to that file. (Previously, the first patch was applied to the\n file specified on the command line, and the names of additional files to\n patch were taken from header lines in the patch file.)\n\n* The -r option now works correctly even if there are rejects in more than\n one file. Use the - argument to discard rejects.\n\n* Rejected hunks come out in unified diff format if the input patch was of\n that format, otherwise in ordinary context diff form. Use the\n --reject-format option to enforce either \"context\" or \"unified\" format.\n Timestamps and the \"diff -p\" (--show-c-function) output are preserved.\n Changed lines in context format reject files are correctly indicated\n with '!' markers as the format defines. Added and removed lines are\n still marked with '+' and '-', respectively.\n\n* The file permissions of reject files are no longer set to match the files\n they modify. Instead, they retain the default permissions. This is\n consistent with reject files produced with the -r option.\n\n* The --binary option disables the heuristic for stripping CRs from\n line endings in patches. This allows to preserve CRs even in mangled\n patches, or in patches generated on non-POSIX systems and without the\n --binary option.\n\n* Backup files for non-existing files are now created with default\n permissions rather than with mode 0: backup files with mode 0 were\n causing problems with applications which do not expect unreadable\n files.\n\n* The -B, -Y, and -z options (--prefix, --basename-prefix, --suffix) now\n imply the simple version control mode, and can be combined.\n\n* Patch rejects more malformed normal format commands and checks for trailing\n garbage. It now recognizes ed commands without addresses.\n\n* Change the default value of PATCH_GET to 0. (Previously, the default was 0\n under POSIXLY_CORRECT and negative otherwise; this is causing problems\n particularly with Perforce.)\n\n* Handle missing timestamps better.\n\n\nPlease email bugs or suggestions to . (Check the Savannah \nproject's bug tracker for a list of known issues.)\n\n\nThanks,\nAndreas\n"},{"id":"127536","messageId":"6672d0160911140045h70243c12w3c56ad925dc70d39@mail.gmail.com","threadId":"21608","inReplyTo":"200911140109.34202.agruen@suse.de","subject":"Re: GNU patch: new 2.6 release","fromName":"Björn Gustavsson","fromEmail":"bgustavsson@gmail.com","sentAt":"2009-11-14T08:45:11Z","receivedAt":"2009-11-14T08:45:11Z","isPatch":false,"sender":{"key":"bgustavsson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/74840?v=4"},"body":"On Sat, Nov 14, 2009 at 1:09 AM, Andreas Gruenbacher wrote:\n> I am pleased to announce my first release of GNU patch,\n\nNice to see a new release.\n\nDo you have any plans to support git-style binary patches?\n\nThat would be very useful in a workflow when you work in git (and have some\nbinary files in the repository), but need to commit your finished work\ninto another VCS (such as Clearcase).\n\n/Björn\n-- \nBjörn Gustavsson, Erlang/OTP, Ericsson AB\n"},{"id":"127539","messageId":"200911141117.29238.agruen@suse.de","threadId":"21608","inReplyTo":"6672d0160911140045h70243c12w3c56ad925dc70d39@mail.gmail.com","subject":"Re: GNU patch: new 2.6 release","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2009-11-14T10:17:29Z","receivedAt":"2009-11-14T10:17:29Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"On Saturday 14 November 2009 09:45:11 am Björn Gustavsson wrote:\n> Do you have any plans to support git-style binary patches?\n\nSupport for git's extended header lines for renames, copies, hashes, file \nmodes would be great. I'll happily take patches or eventually implement it \nmyself. Binary patches are not as high on my wish list, but feel free to send \ncode.\n\n> That would be very useful in a workflow when you work in git (and have some\n> binary files in the repository), but need to commit your finished work\n> into another VCS (such as Clearcase).\n\nIsn't there a better way to do this than with patches?\n\nThanks,\nAndreas\n"},{"id":"127546","messageId":"6672d0160911140427p549dfe66p454376eaed346704@mail.gmail.com","threadId":"21608","inReplyTo":"200911141117.29238.agruen@suse.de","subject":"Re: GNU patch: new 2.6 release","fromName":"Björn Gustavsson","fromEmail":"bgustavsson@gmail.com","sentAt":"2009-11-14T12:27:38Z","receivedAt":"2009-11-14T12:27:38Z","isPatch":false,"sender":{"key":"bgustavsson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/74840?v=4"},"body":"2009/11/14 Andreas Gruenbacher :\n> Support for git's extended header lines for renames, copies, hashes, file\n> modes would be great. I'll happily take patches or eventually implement it\n> myself. Binary patches are not as high on my wish list, but feel free to send\n> code.\n\nSupport for the other extended header lines would be useful for me too.\nI might have a go at implementing them (and binary patches) at some\npoint in the future.\n\n>> That would be very useful in a workflow when you work in git (and have some\n>> binary files in the repository), but need to commit your finished work\n>> into another VCS (such as Clearcase).\n>\n> Isn't there a better way to do this than with patches?\n\nIf there is a better way, I would be very interested in finding out what it is.\n\nFeeding the output from 'git format-patch' to patch is the\nbest way I've had come up with yet. patch (given the '-g 1' option)\nwill automatically check out the files that are to be patched.\nI have wrapped that in a simple script that retrieves the commit\ncomment from the patch and check in the files with that commit\ncomment.\n\n/Björn\n\n-- \nBjörn Gustavsson, Erlang/OTP, Ericsson AB\n"},{"id":"127611","messageId":"200911151437.56228.trast@student.ethz.ch","threadId":"21608","inReplyTo":"6672d0160911140045h70243c12w3c56ad925dc70d39@mail.gmail.com","subject":"Re: GNU patch: new 2.6 release","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T13:37:55Z","receivedAt":"2009-11-15T13:37:55Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Björn Gustavsson wrote:\n> Do you have any plans to support git-style binary patches?\n> \n> That would be very useful in a workflow when you work in git (and have some\n> binary files in the repository), but need to commit your finished work\n> into another VCS (such as Clearcase).\n\nYou can simply use git-apply in this case, it also works outside a git\nrepository.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"127612","messageId":"6672d0160911150602r450ae91fl34f533a39e61ed7@mail.gmail.com","threadId":"21608","inReplyTo":"200911151437.56228.trast@student.ethz.ch","subject":"Re: GNU patch: new 2.6 release","fromName":"Björn Gustavsson","fromEmail":"bgustavsson@gmail.com","sentAt":"2009-11-15T14:02:20Z","receivedAt":"2009-11-15T14:02:20Z","isPatch":false,"sender":{"key":"bgustavsson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/74840?v=4"},"body":"2009/11/15 Thomas Rast :\n> Björn Gustavsson wrote:\n>> That would be very useful in a workflow when you work in git (and have some\n>> binary files in the repository), but need to commit your finished work\n>> into another VCS (such as Clearcase).\n>\n> You can simply use git-apply in this case, it also works outside a git\n> repository.\n\nThanks, I didn't know that. I just assumed that it used the index\nor generally depended on being run in a git repository.\n\nThe patch program does one thing that git-apply does not --\nit can check out the files to be patched (for systems that need\nit, such as Clearcase or RCS). I will have to handle that myself\n(but that is not hard, I can either use 'git diff --name-only' to find\nout the file names or extract the names from the patch itself).\n\n/Björn\n-- \nBjörn Gustavsson, Erlang/OTP, Ericsson AB\n"}]}