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
  48 Technical (heavier)
  49 -------------------
  50
  51 * Libification.  There are many places "run once" mentality is
  52   ingrained in the management of basic data structures, which
  53   need to be fixed.  [Matthias Urlichs is already working on
  54   this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
  55
  56 * Maybe a pack optimizer.
  57
  58   Given a set of objects and a set of refs (probably a handful
  59   branch heads and point release tags), find a set of packs to
  60   allow reasonably minimum download for all of these classes of
  61   people: (1) somebody cloning the repository from scratch, (2)
  62   somebody who tends to follow the master branch head reasonably
  63   closely, (3) somebody who tends to follow only the point
  64   releases.
  65
  66   This needs a matching smart on the dumb protocol downloader.
  67
  68 * Maybe an Emacs VC backend.
  69
  70 * Look at libified GNU diff CVS seems to use, or libxdiff.
  71   [Daniel has his own diff tool almost ready to start
  72   integrating and testing]
  73
  74
  75 Technical (milder)
  76 ------------------
  77
  78 * send-pack/receive-pack protocol updates, to allow the receiver
  79   to report what it did to the ref update requests [DONE].
  80
  81 * Perhaps a smarter HTTP anonymous download via CGI.
  82
  83 * Prepare to enable "always use symbolic refs for HEAD" patch.
  84   We need a timeline to force Porcelains to get ready.  Last
  85   time I looked at them I got an impression that gitweb was not
  86   ready.
  87
  88 * Forbid/ignore pack names that do not conform to the convention
  89   sha1_pack_name() assumes and reject in check_packed_git_idx()
  90   [In pu]
  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   [DONE, with --full-name option like ls-files]
 101
 102 * Any Porcelain-ish we forgot or punted to make usable from
 103   subdirectory?  I think the last pass caught everything and
 104   what are remaining are whole-tree or whole repository
 105   operations.
 106
 107 * diff stopping at the first output; qgit wants to know if this
 108   tree has any A or D from the other tree and nothing else.
 109   Would help internal tree-diff in rev-list as well.
 110
 111 * daemon --strict-symlink.
 112
 113 * Perhaps detect cloning request in upload-pack and cache the
 114   result for next cloning request until any of our refs change.
 115
 116 * Perhaps accept patch to optionally allow '--fuzz' in
 117   'git-apply'.
 118
 119 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 120   to say '\No newline' if both input ends with incomplete
 121   lines.
 122
 123 * Perhaps deal with "Files differ" (binary diff) in non C
 124   locales.
 125
 126 * Maybe grok PGP signed text/plain in applymbox as well.
 127
 128 * Output full path in the "git-rev-list --objects" output, not
 129   just the basename, and see the improved clustering results in
 130   better packing [Tried, but did not work out well].
 131
 132 * Daemon --base-path does not apply automatically to whitelist
 133   somehow feels wrong.  If somebody cares enough, accept
 134   patches.
 135
 136
 137 Technical (trivial)
 138 -------------------
 139
 140 * Daemon --base-path forbidding user-path automatically feels
 141   wrong.  If somebody cares enough, accept patches.
 142
 143 * git-proxy should be spawned with sh -c 'command' $1 $2.
 144
 145 * Versioning scheme.  The next maintenance installment will be
 146   1.0.3 not 1.0.0c.  The next feature release would be 1.1.0 [DONE].
 147
 148 * Either drop supporting Debian myself or coerce patches out of
 149   the official maintainer [DONE -- DROPPED].
 150
 151 * We would want test scripts for the relative directory path
 152   stuff Linus has been working on.  Most of the C-level
 153   commands should be usable with relative directory paths.
 154
 155 * In a freshly created empty repository, `git fetch foo:bar`
 156   works OK, but `git checkout bar` afterwards does not (missing
 157   `.git/HEAD`).
 158
 159 \f
 160 Local Variables:
 161 mode: text
 162 End: