gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Generating *context* diffs out of changesets


From: David Allouche
Subject: Re: [Gnu-arch-users] Re: Generating *context* diffs out of changesets
Date: Fri, 29 Jul 2005 16:15:43 +0200

On Tue, 2005-07-26 at 13:46 +0000, Emilio Lopes wrote:
> Aaron Bentley wrote:
> 
> > Emilio Lopes wrote:
> > 
> >>    - patch 40 implemented the first step
> >>
> >>    - patch 41 was an update from CVS
> >>
> >>    - patch 42 implement the second step of the new feature
> >>
> >> Now I want to send a single *context* diff (generated with 'diff -c')
> >> generated out of changesets 40 and 42, ignoring patch 41 of course.
> > 
> > I don't think that's a generally solvable problem if you require that
> > changes introduced by 41 not appear.  42 may depend on the changes
> > introduced by 41.
> 
> OK, that's right.  I see the problem now.
> 
> >> How, if at all, can I accomplish this with tla?
> > 
> > One option is to take a CVS tree, replay patch-40 and patch-42 into it,
> > and do normal diff against a revlib or pristine tree
> > 
> > [...]
> > 
> 
> Thanks for the examples, it helps a lot.  It seems I'll have to write some
> scripts to automate these tasks.

Another possibility is to change your workflow a bit:

      * Have a --cvs-- import branch where you only do "cvs update; baz
        commit".
      * Have a --devel-- branch (or multiple features branches) tagged
        off the --cvs-- branch where you do your work and merge from the
        --cvs-- branch when you want new stuff
      * merge from --devel-- into --cvs--, then baz diff to get a
        unified diff of your change against upstream, detecting any
        potential textual conflict

You can even get fancy by doing sync-tree with your feature branches in
your --cvs-- branch when your contributed changes are merged, or have a
separate intermediate --merge-- branch where you enrich your --cvs--
branch with patchlogs for accepted patches. That makes for an awkyard
workflow, but it makes it possible to check that upstream did not blow
up the patch when applying it (yes, I had to do that at one point).

-- 
                                                            -- ddaa

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]