-
Notifications
You must be signed in to change notification settings - Fork 8
/
TODO
318 lines (269 loc) · 10.6 KB
/
TODO
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
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
- search should go to right column and highlight
- do we always recenter top when we split - what if near but not at bottom
- side-by-side sometimes shows last line of a chunk with
the next chunk
- '|' should go from sidebyside to merge
- sometimes the split page gets white spaces - 'int bl_count'
- use next_mline in print_merge2
+ discard merge.c
- extract.c should be able to extract half of a word-diff
- extract.c should work on word-merges
- review all test output to make sure it looks right
- document 'p' DOING
- can find_best be optimised more?
- --verbose flag ?? what should it do?
- review commented code and discard some of it
- test on raid code
- possibly encourage "###...####" onto line by itself in diff output
- possibly remember match information while reading patch/merge
to help matching.
- is there anything useful to be done with linenumber information?
- document diff algorithm
- document best-match algorithm
- document merge algorithm
- enhance 'p'
- editmail? reviewmail
- review wiggle failures
- Application of patch-03-MdRaid5Works caused some odd matches
- possible verbosity:
report lines at which each patch was applied.??
- add examples to man page
- Design viewer.
Maybe:
3 windows: before, patch, after
-----------------------------------
p - md.c - wait_event_interruptible
The preceding tabs aren't noticed as being the same...
-----------------------------------
31 March 2005
Some possible targets:
- check new marge code on all tests
- output merge as a diff from original
- handle multi-file patchs, producing new patch or updating files
- improve diff3 markers
- modified
- preserve permissions in created file
- allow output to have just one stream selected of conflicts.
- allow 'output' to include .rej files
- fix "produced this was" -> "produced this way" in man page
other things
- Read a series of patches and determine dependancies
Then push a given patch forward or backward in the list.
Possibly full determination of dependancies isn't needed.
Just pust the target patch until it hits a wall, then
push the wall as far as it goes.
A potential 'wall' happens when inserted text is deleted.
We refine A -> B -> C and see if it can be broken up with
common a->a->a sections and between them,
x->x->y or p->q->q
There can then become x->y->y and p->p->q
But suppose we find x->x->y and p->q->q with no
a->a->a in between. Are we allowed to handle that?
This is a sentence
(is -> was)
This was a sentence
(a -> my)
This was my sentence
Commutine the patches give
This is a sentence
(a -> my)
This is my sentence
(is -> was)
This was my sentence
That seems safe enough. How about insertions and deletions?
This a sentence
(add is)
This is a sentence
(remove a)
This is sentence
This a sentence
(remove a)
This setence
(add is)
This is sentence
Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
make it easier....
So: first sort the blocks (well, the files) and see if there is any overlap
of after-A with before-B.
If not, we update offsets. Maybe store each chunk as offset-from-end-of-last.
If so, we extend both blocks, possibly including other blocks, to get two blocks
that start and end at the same place.
Then run a word-wise merge-like thing. If there are no conflicts, extract the new
intermediate file and create the new diff from that.
So: each patch is a list of files with hunks
the hunks may grow extra context as it is found in other hunks
and may even merge.
To commute two patches:
If a chunk doesn't match any chunk in other file, just retain it.
If it does, expand both chunks with common data from the other
then run the diff code, then extract the new middle
----------------------------
27May2006
I need to improve the browsing mode. Displaying before and
after on the one line doesn't work very well.
I think both the orignal/result and the before/after views need to
to have -/+ lines for any difference.
So, for each newline we need to record whether there are any differences
on the line or not. If there are, we will need to display that
line twice, once before and once after.
This means we need to acknowledge two 'line' cursor positions?
Yes, if we are ever to have an edit cursor...
But don't we only need to edit the 'after'
Probably safer to provide for editing both as we might want to
do that before reapplying the diff.
When we have consecutive newlines that are flagged, how do we display them?
Grouped or interleaved?
Grouped:
- AAA
- BBB
+ aaa
+ bbb
Interleaved
- AAA
+ aaa
- BBB
+ bbb
Grouped is what 'diff -u' generally does, however we know more about the
content of the lines an whether it is a line that has been changed or a larger
chunk. Maybe try one and see...
If a line only has additions, or only has deletions it might be safe to just
display the more complete line.. maybe leave that for wait-and-see too.
For Grouped diff, we need to locate a group. Maybe we flag newlines as
group-begin and group-end.
Need to think this through..
A 'pos' is the end of a line. We only 'sit' on eols that are visible
We know the merger entry that covers this eol, and a position in one stream.
If whole line is in
Unmatched, Unchange, Extraneous,
Then we just show the line undecorated.
If the line contins Changed, we show orig/result as separate lines.
If line contains Changed, AlreadyApplied or Conflict, we show before/after as separate lines
We, when we 'draw_mline'. We first do the 'before/orig' lines.
If there is a Changed we signal that we need a RESULT and put in a '-'
If there is a Changed, AlreadyApplied or Conflict, we signal the need for
an AFTER and put in a '-'.
If either were needed, we put in another line
Grouped diff:
as well as 'pos' we have start and end, and 'side'.
start is the first line in the set containing pos that have CHANGES set.
end is the last line in the same set
size is either 0 if row is a ' ', -1 if a '-' or 1 if row is a '+'
We need to allow for all of this when walking up and down for drawing lines.
TODO
- what is 'cleanlist' meant to do - it seems to badly break things.
DONE - implemented Grouped diffs
DONE - at same time, lines with no diff should show no diff.
- put line/col number is status bar
DONE - allow cursor to move left/right and scroll-on-demand.
- If we have selected 'before', then don't show 'after' lines..
DONE - blank after end and before begining
- better movement:
DONE top
DONE bottom
DONE next/prev diff
next/prev conflict
incr-search
find char pos in search and highlight
multiple finds per line
search to loop around
switch from forward to reverse.
DONE page up/down
DONE beginning/end of line
left-right to handle line breaks.
- handle single .rej file
- allow updates to be saved
- allow editing???
- better colours? configurable?
- extract.c should be able to extract half of a word-diff
- extract.c should work on word-merges
- review all test output to make sure it looks right
- document 'p' DOING
- can find_best be optimised more?
- --verbose flag ?? what should it do?
- review commented code and discard some of it
- test on raid code
- possibly encourage "###...####" onto line by itself in diff output
- possibly remember match information while reading patch/merge
to help matching.
- is there anything useful to be done with linenumber information?
- document diff algorithm
- document best-match algorithm
- document merge algorithm
- enhance 'p'
- editmail? reviewmail
- review wiggle failures
- Application of patch-03-MdRaid5Works caused some odd matches
- possible verbosity:
report lines at which each patch was applied.??
- add examples to man page
- Design viewer.
Maybe:
3 windows: before, patch, after
-----------------------------------
p - md.c - wait_event_interruptible
The preceding tabs aren't noticed as being the same...
-----------------------------------
31 March 2005
Some possible targets:
- check new marge code on all tests
- output merge as a diff from original
- handle multi-file patchs, producing new patch or updating files
- improve diff3 markers
- modified
- preserve permissions in created file
- allow output to have just one stream selected of conflicts.
- allow 'output' to include .rej files
- fix "produced this was" -> "produced this way" in man page
other things
- Read a series of patches and determine dependancies
Then push a given patch forward or backward in the list.
Possibly full determination of dependancies isn't needed.
Just pust the target patch until it hits a wall, then
push the wall as far as it goes.
A potential 'wall' happens when inserted text is deleted.
We refine A -> B -> C and see if it can be broken up with
common a->a->a sections and between them,
x->x->y or p->q->q
There can then become x->y->y and p->p->q
But suppose we find x->x->y and p->q->q with no
a->a->a in between. Are we allowed to handle that?
This is a sentence
(is -> was)
This was a sentence
(a -> my)
This was my sentence
Commutine the patches give
This is a sentence
(a -> my)
This is my sentence
(is -> was)
This was my sentence
That seems safe enough. How about insertions and deletions?
This a sentence
(add is)
This is a sentence
(remove a)
This is sentence
This a sentence
(remove a)
This setence
(add is)
This is sentence
Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
make it easier....
So: first sort the blocks (well, the files) and see if there is any overlap
of after-A with before-B.
If not, we update offsets. Maybe store each chunk as offset-from-end-of-last.
If so, we extend both blocks, possibly including other blocks, to get two blocks
that start and end at the same place.
Then run a word-wise merge-like thing. If there are no conflicts, extract the new
intermediate file and create the new diff from that.
So: each patch is a list of files with hunks
the hunks may grow extra context as it is found in other hunks
and may even merge.
To commute two patches:
If a chunk doesn't match any chunk in other file, just retain it.
If it does, expand both chunks with common data from the other
then run the diff code, then extract the new middle
- move to left in tabs doesn't work right
- check out md.c and 383MDBlocked in demo directory