Обсуждение: [HACKERS] How to submit a patch.

On Sun, 1 Jun 1997, Sean Lyndersay wrote:

> When running regression tests on my system (DEC Alpha running OSF1 v4.0
> Release 564), several tests fail. Some key ones include the int2 and int4,
> but these are caused by changes in the error messages for certain tests.

This can't be helped.  The error messages differ on different machines.
The tests that "fail" on your machine pass on mine and many others.  I
would suggest you don't submit patches to change these.

> I changed the expected files, but came up against another problem: simply
> put, what is the preferred method for submitting a patch?

Here is how I do it.  (I got this from Thomas Lockhart.):

  1) Create directory /usr/src/pgsql/patches, e.g.
       mkdir /usr/src/pgsql/patches

  2) Make a backup of the files you will change, e.g.
       cd /usr/src/pgsql/src/man
       cp psql.1 psql.1.orig

  3) Edit the files, e.g.
       vi psql.1

  4) Make the patch by using diff from the patch directory, e.g.
       cd /usr/src/pgsql/patches
       diff -c ../src/man/psql.1.orig ../src/man/psql.1 > psql.1.patch

  5) E-mail this patch to pgsql-patches@postgresql.org.  Describe the
     purpose of the patch at the top of the message.  Then include
     the text in the patch file (e.g. psql.1.patch).

David Friend                ! cq995@freenet.carleton.ca
Atlantis Scientific Inc.        ! david.friend@atlsci.com
20 Colonnade Rd, Suite 110        ! 613-727-1087 (voice)
Ottawa, Ontario, CANADA  K2E 7M6    ! 800-265-3894 (voice)
ERGOvista Scientific Image Analysis    ! 613-727-5853 (fax)

------------------------------

On Mon, 2 Jun 1997, David Friend wrote:

> On Sun, 1 Jun 1997, Sean Lyndersay wrote:
>
> > When running regression tests on my system (DEC Alpha running OSF1 v4.0
> > Release 564), several tests fail. Some key ones include the int2 and int4,
> > but these are caused by changes in the error messages for certain tests.
>
> This can't be helped.  The error messages differ on different machines.
> The tests that "fail" on your machine pass on mine and many others.  I
> would suggest you don't submit patches to change these.
>
> > I changed the expected files, but came up against another problem: simply
> > put, what is the preferred method for submitting a patch?
>
> Here is how I do it.  (I got this from Thomas Lockhart.):
>
>   1) Create directory /usr/src/pgsql/patches, e.g.
>        mkdir /usr/src/pgsql/patches
>
>   2) Make a backup of the files you will change, e.g.
>        cd /usr/src/pgsql/src/man
>        cp psql.1 psql.1.orig
>
>   3) Edit the files, e.g.
>        vi psql.1
>
>   4) Make the patch by using diff from the patch directory, e.g.
>        cd /usr/src/pgsql/patches
>        diff -c ../src/man/psql.1.orig ../src/man/psql.1 > psql.1.patch

    So *that* is why I don't like your patches :)  That ../ screws me
up every time...never think to add the -p1 to patch when applying :)  At
least its not like some ppl that send me a patch to <insert obscure .c file
here> and expect me to know *where* in the source tree it is :(

    Why not just do:

    cd /usr/src/pgsql
    diff -c src/man/psql.1.orig src/man/psql.1 > /tmp/psql.1.patch


Marc G. Fournier                                 scrappy@hub.org
Systems Administrator @ hub.org              scrappy@freebsd.org

------------------------------

  Here is my catch all solution for diffs. Whenever I change a file,
I copy it on filename.orig. When you run the script from the
pg directory, it will create a file "this.patch" containing a
diff for everything that changed...

    mjl

- ----
#!/bin/csh

rm -f this.patch
touch this.patch

foreach n (`find . -name \*.orig -print`)
    set x=`dirname $n`/`basename $n .orig`
    if( -z $n ) then
        set n='/dev/null'
    endif

    echo "Diffing $x against $n"
    diff -abcdp $n $x >> this.patch

    rm -f $n
    cp $x $x.new
end

------------------------------