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 from now on
  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
  20 Documentation
  21 -------------
  22
  23 * Talk about using rsync just once at the beginning when
  24   initializing a remote repository so that local packs do not
  25   need to be expanded.  I personally do not think we need tool
  26   support for this (but see below about optimized cloning).
  27
  28 * Maybe update tutorial with a toy project that involves two or
  29   three developers.
  30
  31
  32 Design issues
  33 -------------
  34
  35 * Plug-in file-level merges.  On the other hand, we may not even
  36   need this; just tell people to run "xxdiff -U" on the working
  37   tree files.
  38
  39 * Ref namespace management.  Perhaps use refs/local/ suggestion
  40   by Linus. [Does not seem to be high on people's priority list,
  41   and not interested myself.  People can resurrect this
  42   discussion if they want.]
  43
  44 * Perhaps "everything in config file"?  Especially remotes/
  45   shortcuts.  I am modestly negative about this.
  46
  47 * Perhaps "setting umask from git_config()"?  I am modestly
  48   negative about this.
  49
  50
  51 Technical (heavier)
  52 -------------------
  53
  54 * Libification.  There are many places "run once" mentality is
  55   ingrained in the management of basic data structures, which
  56   need to be fixed.  [Matthias Urlichs is already working on
  57   this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
  58
  59 * Maybe a pack optimizer.
  60
  61   Given a set of objects and a set of refs (probably a handful
  62   branch heads and point release tags), find a set of packs to
  63   allow reasonably minimum download for all of these classes of
  64   people: (1) somebody cloning the repository from scratch, (2)
  65   somebody who tends to follow the master branch head reasonably
  66   closely, (3) somebody who tends to follow only the point
  67   releases.
  68
  69   This needs a matching smart on the dumb protocol downloader.
  70
  71 * Maybe an Emacs VC backend.
  72
  73 * Look at libified GNU diff CVS seems to use, or libxdiff.
  74   [Daniel has his own diff tool almost ready to start
  75   integrating and testing]
  76
  77
  78 Technical (milder)
  79 ------------------
  80
  81 * send-pack/receive-pack protocol updates, to allow the receiver
  82   to report what it did to the ref update requests.
  83
  84 * Perhaps a smarter HTTP anonymous download via CGI.
  85
  86 * Prepare to enable "always use symbolic refs for HEAD" patch.
  87   We need a timeline to force Porcelains to get ready.
  88
  89 * Forbid/ignore pack names that do not conform to the convention
  90   sha1_pack_name() assumes and reject in check_packed_git_idx().
  91
  92 * strip leading directory from ls-tree output, to match ls-files
  93   output.
  94
  95   I am of two minds about this one.  diff output must always be
  96   -p1 format no matter where the command was started, and
  97   ls-tree might be easier to use if it matched diff, not
  98   ls-files.
  99
 100 * diff stopping at the first output; qgit wants to know if this
 101   tree has any A or D from the other tree and nothing else.
 102   Would help internal tree-diff in rev-list as well.
 103
 104 * daemon --strict-symlink.
 105
 106 * Perhaps detect cloning request in upload-pack and cache the
 107   result for next cloning request until any of our refs change.
 108
 109 * Perhaps accept patch to optionally allow '--fuzz' in
 110   'git-apply'.
 111
 112 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 113   to say '\No newline' if both input ends with incomplete
 114   lines.
 115
 116 * Perhaps deal with "Files differ" (binary diff) in non C
 117   locales.
 118
 119 * Maybe grok PGP signed text/plain in applymbox as well.
 120
 121 * Output full path in the "git-rev-list --objects" output, not
 122   just the basename, and see the improved clustering results in
 123   better packing [Tried, but did not work out well].
 124
 125
 126 Technical (trivial)
 127 -------------------
 128
 129 * Versioning scheme.  The next maintenance installment will be
 130   1.0.3 not 1.0.0c.  The next feature release would be 1.1.0.
 131
 132 * Either drop supporting Debian myself or coerce patches out of
 133   the official maintainer.
 134
 135 * We would want test scripts for the relative directory path
 136   stuff Linus has been working on.  Most of the C-level
 137   commands should be usable with relative directory paths.
 138
 139 * In a freashly created empty repository, `git fetch foo:bar`
 140   works OK, but `git checkout bar` afterwards does not (missing
 141   `.git/HEAD`).
 142
 143 \f
 144 Local Variables:
 145 mode: text
 146 End: