On Fri, 13 Feb 2009 16:39:44 +0100 Thibaut Paumard <mlotpot.news@free.fr> wrote: > Hi, > > Le 13 févr. 09 à 16:04, Andreas Schildbach a écrit : > > I wonder what's the best workflow to adapt a patch to a changed > > source. > > [...] > > Even finding out the cause of the failure by examining the .rej file > > has > > been no success. You have to know what the change was trying to achieve in order to mould the patch into the new code. > And yet you can't adapt the patch if you don't know why it failed. > Look at it this way: if you can't find it out yourself, how is a > computer program supposed to do so? > > Basically, I see two possible reasons why a patch would fail: > 1- the lines to patch have moved, perhaps to another file: use e.g. > grep to find where they are now; patch can usually get around those situations, it just moans about offsets. > 2- the lines to patch have been modified: you need to decide wether > you still need the patch (in an adapted form). Check whether the bug > that is being fixed by the patch still exists. You can also try 'wiggle' but do it in a temporary directory so that you don't end up with a mess you cannot fix. wiggle is quite clever (much cleverer than patch itself) and has ways of resolving many patch conflicts. Another useful tool is meld - a graphical diff viewer/editor that can show you three way diffs - the previous unpatched, the upstream and the one you want - containing the effect of the patch on the upstream. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpGxG07nWB8Q.pgp
Description: PGP signature