Get merge2 to pass all the tests...
[wiggle/upstream.git] / TODO
blobcdd9e66ab7d905b993ef193a0a0897e00bc5c247
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
5 - document 'p' DOING
6 - can find_best be optimised more?
7 - --verbose flag ?? what should it do?
8 - review commented code and discard some of it
9 - test on raid code
10 - possibly encourage "###...####" onto line by itself in diff output
11 - possibly remember match information while reading patch/merge
12   to help matching.
13 - is there anything useful to be done with linenumber information?
14 - document diff algorithm
15 - document best-match algorithm
16 - document merge algorithm
17 - enhance 'p'
18   - editmail?  reviewmail
19   - review wiggle failures
21 - Application of patch-03-MdRaid5Works caused some odd matches
23 - possible verbosity:
24      report lines at which each patch was applied.??
25 - add examples to man page
27 - Design viewer.
28    Maybe:
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 -----------------------------------
37 31 March 2005
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
44  - modified
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
50 other things
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,
59     x->x->y or p->q->q
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?
64    This is a sentence
65     (is -> was)
66    This was a sentence
67     (a -> my)
68    This was my sentence
70    Commutine the patches give
71    This is a sentence
72     (a -> my)
73    This is my sentence
74     (is -> was)
75    This was my sentence
77    That seems safe enough.  How about insertions and deletions?
78     This a sentence 
79      (add is)
80     This is a sentence
81       (remove a)
82     This is sentence 
84     This a sentence
85       (remove a)
86     This setence
87       (add is)
88     This is sentence
90     Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
91     make it easier....
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
104        and may even merge.
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