4 The latest copy of this document is found at
6 http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
9 What to expect until and after 1.0
10 ==================================
12 This is written in a form of to-do list for me, so if I say
13 "accept patch", it means I do not currently plan to do that
14 myself. People interested in seeing it materialize please take
15 a hint. Also whatever I marked "Perhaps" do not have to happen
16 if ever -- only if somebody cares enough and submits a clean
19 Only handful things remain until 1.0.
25 * Accept patches from people who actually have done CVS
26 migration and update the cvs-migration documentation.
27 Link the documentation from the main git.txt page.
29 * Talk about using rsync just once at the beginning when
30 initializing a remote repository so that local packs do not
31 need to be expanded. I personally do not think we need tool
32 support for this (but see below about optimized cloning).
34 * Maybe update tutorial with a toy project that involves two or
37 * Update tutorial to cover setting up repository hooks to do
38 common tasks [Mostly done, with Carl's help].
40 * Do we still have missing docs? If so accept patches to finish
43 * Accept patches to talk about "Whoops, it broke. What's
44 next?" [I think this is done].
46 * Accept patches to make formatted tables in asciidoc to work
47 well in both html and man pages (see git-diff(1)) [DONE --
50 * Work around multiple synopses lines in manual pages
51 (e.g. git-bisect) [DONE -- avoid them ;-)].
57 * Libification. There are many places "run once" mentality is
58 ingrained in the management of basic data structures, which
59 need to be fixed. [Matthias Urlichs is already working on
60 this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>; Post
63 * Maybe a pack optimizer.
65 Given a set of objects and a set of refs (probably a handful
66 branch heads and point release tags), find a set of packs to
67 allow reasonably minimum download for all of these classes of
68 people: (1) somebody cloning the repository from scratch, (2)
69 somebody who tends to follow the master branch head reasonably
70 closely, (3) somebody who tends to follow only the point
73 This needs a matching smart on the dumb protocol downloader.
74 [Definitely post 1.0].
76 * Maybe an Emacs VC backend.
78 * Look at libified GNU diff CVS seems to use, or libxdiff.
79 [Daniel has his own diff tool almost ready to start
80 integrating and testing; Post 1.0]
82 * Plug-in file-level merges [Post 1.0]. On the other hand, we
83 may not even need this; just tell people to run "xxdiff -U" on
84 the working tree files.
86 * Ref namespace management. Perhaps use refs/local/ suggestion
87 by Linus. [Does not seem to be high on people's priority list,
88 and not interested myself. People can resurrect this
89 discussion if they want.]
95 * strip leading directory from ls-tree output, to match ls-files
98 I am of two minds about this one. diff output must always be
99 -p1 format no matter where the command was started, and
100 ls-tree might be easier to use if it matched diff, not
103 * diff stopping at the first output; qgit wants to know if this
104 tree has any A or D from the other tree and nothing else.
105 Would help internal tree-diff in rev-list as well [can be post
108 * merge-recursive needs to register conflicting paths as higher
109 stage entries in the index. For that, it first needs to
110 construct three trees whose paths are already renamed, and
111 call 3-way read-tree. Alternatively, update-index needs to
112 give it a way to construct higher stages [DONE using the
113 "alternatively" implementation].
115 * daemon --strict-symlink [can be post 1.0].
117 * Binary package split. Plan laid out and discussion mostly
118 done. [RPM side done; Debian side thrown over the wall.]
120 * Perhaps detect cloning request in upload-pack and cache the
121 result for next cloning request until any of our refs change.
123 * Perhaps accept patch to optionally allow '--fuzz' in
126 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
127 to say '\No newline' if both input ends with incomplete
130 * Maybe grok PGP signed text/plain in applymbox as well.
132 * Enhance "git repack" to not always use --all; this would be
133 handy if the repository contains wagging heads like "pu" in
136 * Output full path in the "git-rev-list --objects" output, not
137 just the basename, and see the improved clustering results in
138 better packing [Tried, but did not work out well].
144 * We would want test scripts for the relative directory path
145 stuff Linus has been working on. Most of the C-level
146 commands should be usable with relative directory paths.
148 * In a freashly created empty repository, `git fetch foo:bar`
149 works OK, but `git checkout bar` afterwards does not (missing