[OT] patches, was Re: [using gcc book] compound literals

[Chris Devers <cdevers at pobox dot com>]

On Tue, 26 Aug 2003, Russ Allbery wrote:

> As a long-time user of GCC, thank you *very* much for doing this work.
> I think it's extremely valuable and useful, and it's the sort of work
> that tends not to be as sexy in the free software world.  You deserve a
> lot of accolades!

:)


Okay, enough of that, I want to submit some patches, but am having a hard
time with this.

I sent a mail to Gerald Pfeifer (as he was the person that pointed me
towards the -u3p switches for `diff`), but the editor at FSF that I'm
working with indicated that he may be in Austria, so it may be off-hours
for him to reply at this point.

Here's the question I sent him:


May I ask for a step by step overview of how the diff/patch cycle is
typically done?  The versions of the files I've been working with have
been out of sync with gcc-3_3-branch in CVS for at least a couple of weeks
now, and I know some parts have changed out from under me.

(The whole section on PowerPC Windows -- a product I hadn't even heard of
before getting involved with this book -- was deleted before I could get a
chance to do so, and has been replaced with a much longer section that
itself needs to be examined now. Also, hilariously, the material after the
discussion of PPC/Windows, or now just Windows, has been rearranged such
that it comes up... well, nowhere that I can find. Moving target indeed,
but that's neither here nor there at the moment. *ahem*)

I want to merge those changes into what I'm working on, then come up with
a diff of my changes that would be suitable for submission to the list for
review. With that in mind, I assume the process is:

  1.   diff the custom edit against current a CVS checkout

  2.   patch my version against CVS to bring in new material
  2.a  make sure that this introduced no new errors & fix as needed

  3.   produce a fresh diff between my now up-to-date version & CVS

  4.   submit the final diff

Sound about right?

I tried to do this, and my edits were clobbered. It looks like my changes
of mine were thrown out, and my work directory now has a copy of current
CVS -- with none of my edits preserved.

Fortunately I made a tarball before changing anything, so I can start over
from scratch here, but I want to do it properly this time :)

Here's the steps I did:

  * run all diffs

        for texi in *texi
        do
            diff -u3p ../gcc/gcc/doc/$texi $texi > \
                ../diffs/$texi.diff
        done

  * patch each file

        for texi in *texi
        do
            patch -i ../diffs/$texi.diff $texi
        done

  * I don't get any further, because my edits have evaporated

I've got a feeling that I reversed the arguments in either the diff or the
patch call, but the man pages don't really offer clearer examples.

Can I ask what the syntax for the diff & patch lines are, and if there's
anything else I need to be doing here? Do people generally have shell
scripts to automate this (I would assume so), and if so could you share
any relevant excerpts?



<summary>

In a nutshell, do any of you script the diff/patch process, and
if so may I see a sample of how you invoke the relevant commands?

</summary>



(I'm primarily working on a Mac, but I believe that the
 system has standard versions of all the relevant tools:

  $ /usr/bin/diff -v
  diff - GNU diffutils version 2.7

  $ /sw/bin/diff -v
  diff (GNU diffutils) 2.8.1
  Copyright (C) 2002 Free Software Foundation, Inc.

  $ /usr/bin/patch -v
  patch 2.5.4
  Copyright 1984-1988 Larry Wall
  Copyright 1989-1999 Free Software Foundation, Inc.

etc.)



-- 
Chris Devers        cdevers@pobox.com
http://devers.homeip.net:8080/resume/

debugging, n.
Removing a BUG, either by tinkering with the program or by amending the
program specification so that the side effect of the bug is published as
a desirable feature. See also KLUDGE; ONE-LINE PATCH; STEPWISE REFINEMENT.

    -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995