On Tue, 2010-06-15 at 08:55 -0400, R P Herrold wrote:
First, am I going about this the right way?
no -- Usually one unrolls the old tree, applies the patches to the old; and then unrolls the new in a directory 'next to' the first, and diffs from a point above the top of each
What would that gain me? Following this procedure would get me a big diff showing the differences between the old (patched) version and the new (unpatched) version. But that would contain a list of all of the stuff in the new version which probably doesn't need to be changed, and revert the patches from the previous patched version. In other words, unless I'm looking at this backward somehow, I don't see the point.
This produces a new patch set, which may already have some of what the older patches formerly needed to do (or a wholly different approach, when two forks diverge)
It would also revert the old patch set, wouldn't it?
And if so, is there a way to automate the process as described in the previous paragraph?
Early automation of a partially understood technology seems like a premature optimization ;)
Ah.... but having the computer tell me that I forgot to include the change made to line X in the old patch in my newly rewritten file would be a lot easier (and probably more reliable) than the Mark I Eyeball method.