2 - extract.c should be able to extract half of a word-diff
3 - extract.c should work on word-merges
4 - review all test output to make sure it looks right
6 - can find_best be optimised more?
7 - --verbose flag ?? what should it do?
8 - review commented code and discard some of it
10 - possibly encourage "###...####" onto line by itself in diff output
11 - possibly remember match information while reading patch/merge
13 - is there anything useful to be done with linenumber information?
14 - document diff algorithm
15 - document best-match algorithm
16 - document merge algorithm
18 - editmail? reviewmail
19 - review wiggle failures
21 - Application of patch-03-MdRaid5Works caused some odd matches
24 report lines at which each patch was applied.??
25 - add examples to man page
29 3 windows: before, patch, after
31 -----------------------------------
32 p - md.c - wait_event_interruptible
33 The preceeding tabs aren't noticed as being the same...
36 -----------------------------------
38 Some possible targets:
40 - check new marge code on all tests
41 - output merge as a diff from original
42 - handle multi-file patchs, producing new patch or updating files
43 - improve diff3 markers
45 - preserve permissions in created file
46 - allow output to have just one stream selected of conflicts.
47 - allow 'output' to include .rej files
48 - fix "produced this was" -> "produced this way" in man page
51 - Read a series of patches and determine dependancies
52 Then push a given patch forward or backward in the list.
53 Possibly full determination of dependancies isn't needed.
54 Just pust the target patch until it hits a wall, then
55 push the wall as far as it goes.
56 A potential 'wall' happens when inserted text is deleted.
57 We refine A -> B -> C and see if it can be broken up with
58 common a->a->a sections and between them,
60 There can then become x->y->y and p->p->q
61 But suppose we find x->x->y and p->q->q with no
62 a->a->a in between. Are we allowed to handle that?
70 Commutine the patches give
77 That seems safe enough. How about insertions and deletions?
90 Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
94 So: first sort the blocks (well, the files) and see if there is any overlap
95 of after-A with before-B.
96 If not, we update offsets. Maybe store each chunk as offset-from-end-of-last.
97 If so, we extend both blocks, possibly including other blocks, to get two blocks
98 that start and end at the same place.
99 Then run a word-wise merge-like thing. If there are no conflicts, extract the new
100 intermediate file and create the new diff from that.
102 So: each patch is a list of files with hunks
103 the hunks may grow extra context as it is found in other hunks
105 To commute two patches:
106 If a chunk doesn't match any chunk in other file, just retain it.
107 If it does, expand both chunks with common data from the other
108 then run the diff code, then extract the new middle