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
|
This is my current list of open issues with the patch scripts. I would
like to do the most intrusive changes before syncing up with the
Savannah CVS. Of course, contributions are very welcome. It wouldn't
hurt to know if you want to work on some of the issues in advance to
avoid duplicate work, though :)
-- Andreas Gruenbacher <agruen@suse.de>
General:
- Test if patches/ can be moved with environment variable as
planned.
- Abstract backup operations to/from the .pc/ directory, so that
optionally something like rcs can be used instead of
lib/backup-files?
- Add regression test suite; the scripts were broken often enough
already...
- Add a ~/.quiltrc that contains default options for individual
commands, similar to ~/.cvsrc. Also requires some more
negative options so that the effects of ~/.quiltrc can be
reversed.
- Add something similar to cvs diff, which scans all files for
changes that have not been folded back into their patches,
similar to:
`for p in $(quilt series); do quilt diff -z $p; done'?
- Allow to add a directory? Then we could detect also new files
in the directory, without having to add them individually.
- Add option for creating hard links.
- Instead of passing around and storing in applied-patches the
short patch name (=patch file name with .dif .diff .patch .gz
.bz2 stripped), translate from short names to real file names
an the user interface, and work with full names internally.
This will simplify regexp matching in several functions.
- Support different diff/patch options for different patches.
(By specifying them in the series file?)
Documentation:
- How to rediff with pushpatch -f / poppatch -f?
- How to import a new version of a patch?
- How to import a complete directory, before doing
wild changes? (This will also cause new files to end up in the
patch.)
quilt refresh:
- Add an -m option similar to `cvs commit -m "..."' to simplify
keeping a change log in the patch documentation?
parse-patch:
- Handle SIGINT in parse-patch -u (in the part that moves the
temp file to the patch)?
backup-files:
- Extend so that it can also copy files instead of hard linking,
and when hard links are not possible. Also add option to
disallow hard links on the original file (for patchadd).
- SIGINT handling?
quilt import:
- Add option to replace the currently applied patch with a new
one, by backing out the topmost patch first.
- Diff -u the documentation of the old and new file, unless one
of them is empty. Let the user decide whether to keep the left
or the right documentation, or to merge them both. (-d{ona}?)
quilt add:
- Add option for creating (or rather, leaving) hard links.
quilt setup:
- spec2series also prints -p1; omit.
quilt patches:
- Add something so that it's possible to show a list of all
patches, with those patches marked that modify the
specified file.
rpatch:
- If not removing the topmost patch, add checks if any files are
hidden by later patches. If so, refuse to remove patch! (Note
that poppatch takes care of that currently.)
apatch:
- Allow to add a patch in the middle of the applied series, and
inject the patch in its proper position in applied-patches.
Needs to check if any of the files in the patch are touched by
later patches.
touched_by_patch:
- Implement more of patch's filename heuristic: The following
file is not recognized, for example...
*** linux/drivers/parport/parport_cs.c.orig Sun Jun 23 09:20:21 2002
--- linux/drivers/parport/parport_cs.c Sun Jun 23 09:21:02 2002
***************
*** 48,53 ****
--- 48,54 ----
#include <linux/parport.h>
#include <linux/parport_pc.h>
+ #include <linux/major.h>
#include <pcmcia/version.h>
#include <pcmcia/cs_types.h>
|