TODO

   1 The GIT To-Do File
   2 ==================
   3
   4   The latest copy of this document is found at
   5
   6     http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
   7
   8
   9 What to expect until and after 1.0
  10 ==================================
  11
  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
  17 patch, perhaps ;-).
  18
  19 Only handful things remain until 1.0.
  20
  21
  22 Documentation
  23 -------------
  24
  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.
  28
  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).
  33
  34 * Maybe update tutorial with a toy project that involves two or
  35   three developers.
  36
  37 * Update tutorial to cover setting up repository hooks to do
  38   common tasks [Mostly done, with Carl's help].
  39
  40 * Do we still have missing docs?  If so accept patches to finish
  41   them.
  42
  43 * Accept patches to talk about "Whoops, it broke.  What's
  44   next?" [ONGOING].
  45
  46 * Accept patches to make formatted tables in asciidoc to work
  47   well in both html and man pages (see git-diff(1)) [DONE --
  48   avoid them ;-)].
  49
  50 * Work around multiple synopses lines in manual pages
  51   (e.g. git-bisect) [DONE -- avoid them ;-)].
  52
  53
  54 Technical (heavier)
  55 -------------------
  56
  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
  61   1.0].
  62
  63 * Maybe a pack optimizer.
  64
  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
  71   releases.
  72
  73   This needs a matching smart on the dumb protocol downloader.
  74   [Definitely post 1.0].
  75
  76 * Maybe an Emacs VC backend.
  77
  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]
  81
  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.
  85
  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.]
  90
  91
  92 Technical (milder)
  93 ------------------
  94
  95 * strip leading directory from ls-tree output, to match ls-files
  96   output.
  97
  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
 101   ls-files.
 102
 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
 106   1.0].
 107
 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 [can be post 1.0, but
 113   nicer to have in 1.0].
 114
 115 * daemon --strict-symlink [can be post 1.0].
 116
 117 * Binary package split.  Plan laid out and discussion mostly
 118   done. [RPM side done; Debian side thrown over the wall.]
 119
 120 * Perhaps detect cloning request in upload-pack and cache the
 121   result for next cloning request until any of our refs change.
 122
 123 * Perhaps accept patch to optionally allow '--fuzz' in
 124   'git-apply'.
 125
 126 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 127   to say '\No newline' if both input ends with incomplete
 128   lines.
 129
 130 * Maybe grok PGP signed text/plain in applymbox as well.
 131
 132 * Enhance "git repack" to not always use --all; this would be
 133   handy if the repository contains wagging heads like "pu" in
 134   git.git repository.
 135
 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].
 139
 140
 141 Technical (trivial)
 142 -------------------
 143
 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.
 147
 148 * In a freashly created empty repository, `git fetch foo:bar`
 149   works OK, but `git checkout bar` afterwards does not (missing
 150   `.git/HEAD`).
 151
 152 \f
 153 Local Variables:
 154 mode: text
 155 End: