From xemacs-m  Fri May  9 08:07:11 1997
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id IAA25101
	for <xemacs-beta@xemacs.org>; Fri, 9 May 1997 08:07:09 -0500 (CDT)
Received: (from tor@localhost)
	by pallas.spacetec.no (8.8.5/8.8.5) id PAA27453
	for xemacs-beta@xemacs.org; Fri, 9 May 1997 15:07:32 +0200
Message-Id: <199705091307.PAA27453@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Fri, 9 May 1997 15:07:30 +0200
In-Reply-To: Neal Becker <neal@ctd.comsat.com>
       "patch-2.2" (May  9, 13:51)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: xemacs-beta@xemacs.org
Subject: Re: patch-2.2

On May 9, 13:51, Neal Becker wrote:
>Has anyone tried patch-2.2 with the latest xemacs patch?  I just
>noticed something really strange.  I did 
>
>gunzip < xemacs-xxxx.patch.gz | patch -p1 -s
>
>as always.  The patch succeeded, but there's no yyy.orig files in the
>xemacs tree.  Does patch not backup the originals by default anymore?
>That would really suck.

Agreed.  I haven't installed patch 2.2 yet, because I don't like what I see 
in the NEWS file:

* Patch now complies better with POSIX.2 if your host complies with POSIX.1.

  Therefore:
  - By default, no backups are made.  Set the VERSION_CONTROL environment
    variable to "existing" if you prefer patch's traditional behavior.
...
POSIX didn't use to suck that much, did it?  I used to like it..
I hate using environment variables for things like this, it means that
I always have to do 'env|grep VER' etc. before I dare execute anything.

And then it says:
  - Names of files to be patched are taken first from *** line and then from
    --- line of context diffs; then from Index: line; /dev/tty is
    consulted if none of the above files exist.  However, if the patch
    appears to create a file, the file does not have to exist: instead,
    the first name with the longest existing directory prefix is taken.
...
Which means that patch-2.2 will patch the wrong files in traditional
Linux patch files, which look like this:
diff -u --recursive --new-file v2.1.8/linux/CREDITS linux/CREDITS
--- v2.1.8/linux/CREDITS        Sun Nov 10 20:12:06 1996
+++ linux/CREDITS       Tue Nov 12 10:40:04 1996

(it will patch v2.1.8/linux/CREDITS instead of linux/CREDITS)

It will also fail for patches created like this (which is more or less
how I always create patches):

diff -u file.c~ file.c

It basically works backwards compared to patch-2.1 as far as I can see.

Arrgh..

Tor

