Update 2005-08-28
[git.git] / TODO
1 What to expect after 0.99.5
2 ===========================
3
4 This is written in a form of to-do list for me, so if I say
5 "accept patch", it means I do not currently plan to do that
6 myself.  People interested in seeing it materialize please take
7 a hint.
8
9
10 Documentation
11 -------------
12
13 * Accept patches from people who actually have done CVS
14   migration and update the cvs-migration documentation.
15   Link the documentation from the main git.txt page.
16
17 * Link howto docs from the git.txt page. [DONE]
18
19 * Update the SubmittingPatches document to add MUA specific
20   hints on how to disable unwanted MIME and flowed-text by
21   collecting past list postings [DONE].  Accept patches from
22   people who were hit by shiny blue bat to update the same [IN
23   PROGRESS].
24
25 * Talk about using rsync just once at the beginning when
26   initializing a remote repository so that local packs do not
27   need to be expanded.  I personally do not think we need tool
28   support for this.
29
30 * Update tutorial to cover shared repository style a bit more,
31   maybe with a toy project that involves two or three
32   repositories.
33
34 * Update tutorial to cover setting up repository hooks to do
35   common tasks. [IN PROGRESS]
36
37 * Get help to properly use asciidoc in tutorial.
38
39 * Maybe justify and demonstrate an Octopus in the tutorial.  Add
40   it to the glossary.
41
42
43 Technical (heavier)
44 -------------------
45
46 * Tony Luck reported an unfortunate glitch in the 3-way merge.
47   Encourage discussions to come up with a not-so-expensive way
48   to catch the kind of ambiguities that led to his misery.
49   [Underway.  Thanks Daniel and Fredrik for taking an
50   initiative.]
51
52 * We might want to optimize cloning with GIT native transport
53   not to explode the pack, and store it in objects/pack instead.
54   We would need a tool to generate an idx file out of a pack
55   file for this.  Also this itself may turn out to be a bad
56   idea, making the set of packs in repositories everybody has
57   different from each other.
58
59 * Maybe a pack optimizer.  I am not convinced that packing all
60   objects into a single pack and removing all the existing pack
61   is the right way to go, since that would work against people
62   who already have those packs.
63
64
65 Technical (milder)
66 ------------------
67
68 * When the branch head pointed by $GIT_DIR/HEAD changes while
69   the index file and working tree are looking the other way
70   (e.g. somebody pushed into your repository, or you ran "git
71   fetch" to update the ref your working tree is on), "git
72   checkout" without -f gets confused.  Figure out a good way to
73   handle this. [DONE]
74
75   We still have the same issue with "git fetch".  Fetching into
76   the branch one is on _may_ need to do the same thing as
77   fetching into anonymous head and then do the resolve.  At
78   least it needs a warning. [DONE]
79
80 * "git commit -m" should work for initial commits and perhaps
81   merge commits as well.  Warning about merge is still a good
82   thing to do, while -m is useful in scripted non-interactive
83   use, so we need to be careful. [DONE]
84
85 * Encourage concrete proposals to commit log message templates
86   we discussed some time ago.
87
88 * Bug Ryan and work with him to update send-email easier to use.
89   [Resurrected it for Debian build.]
90
91 * Look at portability fixes from Jason Riedy
92
93     http://www.cs.berkeley.edu/~ejr/gits/git.git#portable 
94
95   [Looked at it. Still undecided.]
96
97 * Accept patches to cause "read-tree -u" delete a directory when
98   it makes it empty.
99
100 * Perhaps accept patches to introduce the concept of "patch flow
101   expressed as ref mappings" Josef has been advocating about.
102
103 * Perhaps accept patches to do undo/redo.
104
105 * MIMEified applymbox to grok B and Q encodings in headers and
106   turn them into UTF-8; unwrap QP; explode multipart.
107   [DONE. waiting for a bug to happen ;-) ]
108
109 * "git cherry-pick" that applies the patch an existing commit
110   introduces in its ancestry chain, possibly using the 3-way
111   merge machinery. [DONE]
112
113 * Update rebase using the cherry-pick command. [DONE]
114
115 * Redo "git revert" using 3-way merge machinery. [DONE]
116
117 * A tool to detect, show and prune already merged topic
118   branches.
119
120 * Set up an automated documentation rebuilding procedure at
121   kernel.org, using update hook mechanism. [DONE]  Describe it
122   in a howto form [DONE].
123
124 * Enhance "git repack" to not always use --all; this would be
125   handy if the repository contains wagging heads like "pu" in
126   git.git repository.
127
128 * Accept and apply "git repack --all" patch, except the part
129   that removes the existing packs. [Undecided]
130
131 * Internally split the project into non-doc and doc parts; add
132   an extra root for the doc part and merge from it; move the
133   internal doc source to a separate repository, like the +Meta
134   repository; experiment if this results in a reasonable
135   workflow, and document it in howto form if it does.
136
137 * Add names to all nodes in show-branch.
138
139 * Option to limit rename detection for more than N paths.
140
141
142 Technical (trivial)
143 -------------------
144
145 * Look at and merge Debian fixes from Tommi [Done].
146
147 * Perhaps "git branch -d" to delete a branch.
148
149 * Remove "git clone-dumb-http".
150
151 * We would want test scripts for the relative directory path
152   stuff Linus has been working on.  So far, the following
153   commands should be usable with relative directory paths:
154
155     update-cache
156     ls-files
157     diff-files
158     diff-cache
159     diff-tree
160     rev-list
161
162 \f
163 Local Variables:
164 mode: text
165 End: