-
Notifications
You must be signed in to change notification settings - Fork 8
/
ANNOUNCE
95 lines (75 loc) · 4.04 KB
/
ANNOUNCE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
ANNOUNCE: wiggle - a tool for applying patches with conflicts
I am pleased to announce the first public release of 'wiggle'.
Wiggle is a program for applying patches that 'patch' cannot
apply due to conflicting changes in the original.
Wiggle will always apply all changes in the patch to the original.
If it cannot find a way to cleanly apply a patch, it inserts it
in the original in a manner similar to 'merge', and reports an
unresolvable conflict. Such a conflict will look like:
<<<<<<<
Some text from
the original file
|||||||
Some text that the patch changes
=======
Some text that is the result of the patch
>>>>>>>
with the meaning that the "text that the patch changes"
was expected somewhere in the "text from the original file"
and should be replaced with "the result of the patch".
wiggle analyses the file and the patch in terms of words rather than
whole lines and so is able to find matches that patch is
unable to find. If a patch changes a word at the end of a line, and
a word at the start of that line has been modified since the patch
was made, then wiggle will have no trouble applying the patch.
wiggle has proved very useful for back-porting patches that were
generated for the development kernel, onto the stable kernel.
Sometimes it does exactly the right thing with the patch. When it doesn't
it reports a conflict which is easy to resolve with an understanding of
what the code and the patch were trying to achieve.
Wiggle is available under the GPL and can be fetched from:
http://www.cse.unsw.edu.au/~neilb/source/wiggle/
The name 'wiggle' was inspired by Andrew Morton's comment:
The problem I find is that I often want to take
(file1+patch) -> file2,
when I don't have file1. But merge tools want to take
(file1|file2) -> file3.
I haven't seen a graphical tool which helps you to wiggle a patch
into a file.
which google can find for you:
http://www.google.com/search?q=graphical+tool+which+helps+you+to+wiggle+a+patch
It isn't a graphical tool, but it is a good first step.
NOTES:
This release contains a 'tests' directory with a number of test cases
that have proved invaluable in developing the program and my
understanding of the subtleties of some of the issues involved. If you
find a case where wiggle behaves sub-optimally (e.g. dumps core),
please consider sending me a test case to add to the tests directory.
This release also contains a script 'p' and accompanying 'p.help'.
This is a script that I use for patch management for my kernel patches
and it makes use of wiggle to allow me to apply patches that
'patch' cannot manage. It is included both as an example of
how wiggle can be used, and as a tool that some might find useful.
One shortcoming I find with wiggle is that I would like to be able
to 'see' what it has done. I would love it if someone were to write
a program that allowed the results of wiggle to be visualised.
The closest that I have come to imagining a workable UI is to
have two side-by-side windows, one of which shows the original patch,
and the other shows a "diff -u" of before and after wiggle has done it's
thing, and to have these windows automatically aligned so that when
a change is shown in one, the corresponding change appears in the other.
Maybe something like tkdiff, but that knows about patches and knows
about word-based diffs....
Wiggle is also able to perform a function similar to 'diff' and show the
differences and similarities between two files. It can show these differences
and similarities at a word-by-word level. The output format is not machine
readable as the character sequences used to delimit inserted and deleted
words are not quoted in the output. Hence this format will probably change
at some stage and should not be depended upon.
If you read the source, beware of comments: they were probably written
while I was still trying to understand the issues myself, and so are
probably wrong and out-of-date. I would like to review all the code and
comments, but if I wait until I do that before releasing it, it'll never
get released!
NeilBrown
The University of New South Wales