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 Tool Renames Plan
  10 =================
  11
  12  - Immedately after 0.99.9, the backward compatible symbolic
  13    links in $(bindir) will be removed [DONE].
  14
  15    git-ssh-push and git-ssh-pull pair is not going away if ever.
  16    Each of these old-name commands continues to invoke its
  17    old-name counterpart on the other end.
  18
  19  - There was a discussion to move bulk of the git-* programs out
  20    of /usr/bin and use /usr/lib/git; the central mechanism was
  21    done, but the actual move is postponed post 1.0.
  22
  23
  24 What to expect after 0.99.9
  25 ===========================
  26
  27 This is written in a form of to-do list for me, so if I say
  28 "accept patch", it means I do not currently plan to do that
  29 myself.  People interested in seeing it materialize please take
  30 a hint.  Also whatever I marked "Perhaps" do not have to happen
  31 if ever -- only if somebody cares enough and submits a clean
  32 patch, perhaps ;-).
  33
  34
  35 Documentation
  36 -------------
  37
  38 * Help Jon Loeliger to find place in the documentation to place
  39   his drawing [DONE].
  40
  41 * Accept patches from people who actually have done CVS
  42   migration and update the cvs-migration documentation.
  43   Link the documentation from the main git.txt page.
  44
  45 * Talk about using rsync just once at the beginning when
  46   initializing a remote repository so that local packs do not
  47   need to be expanded.  I personally do not think we need tool
  48   support for this (but see below about optimized cloning).
  49
  50 * Maybe update tutorial with a toy project that involves two or
  51   three developers.
  52
  53 * Update tutorial to cover setting up repository hooks to do
  54   common tasks.
  55
  56 * Do we still have missing docs?  If so accept patches to finish
  57   them.
  58
  59 * Accept patches to talk about "Whoops, it broke.  What's
  60   next?" [Started].
  61
  62 * Accept patches to make formatted tables in asciidoc to work
  63   well in both html and man pages (see git-diff(1)).
  64
  65
  66 Technical (heavier)
  67 -------------------
  68
  69 * Assess the side effects of "make the rest of the things
  70   magically work from any subdirectory" change by Linus.  It is
  71   a good change in principle and we would like to have that
  72   behaviour but some tool implementations I am sure are assuming
  73   to never run from anywhere other than the top. [Post 1.0]
  74
  75 * Ref namespace management.  Perhaps use refs/local/ suggestion
  76   by Linus.
  77
  78 * Git daemon, when deployed at kernel.org, might turn out to be
  79   quite a burden, since it needs to generate customized packs
  80   every time a new request comes in.  It may be worthwhile to
  81   precompute some packs for popular sets of heads downloaders
  82   have and serve that, even if that could give more than the
  83   client asks for in some cases.  We will know about this soon
  84   enough [DONE part to allow using precomputed pack, but not
  85   dynamic caching part].
  86
  87 * Libification.  There are many places "run once" mentality is
  88   ingrained in the management of basic data structures, which
  89   need to be fixed.  [Matthias Urlichs is already working on
  90   this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>; Post
  91   1.0].
  92
  93 * Maybe a pack optimizer.
  94
  95   Given a set of objects and a set of refs (probably a handful
  96   branch heads and point release tags), find a set of packs to
  97   allow reasonably minimum download for all of these classes of
  98   people: (1) somebody cloning the repository from scratch, (2)
  99   somebody who tends to follow the master branch head reasonably
 100   closely, (3) somebody who tends to follow only the point
 101   releases.
 102
 103 * Maybe an Emacs VC backend.
 104
 105 * 'git split-projects'?  This requires updated 'git-rev-list' to
 106   skip irrelevant commits.
 107   Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>
 108
 109 * Look at libified GNU diff CVS seems to use, or libxdiff.
 110   [Daniel has his own diff tool almost ready to start
 111   integrating and testing; Post 1.0]
 112
 113 * Plug-in file-level merges [Post 1.0].
 114
 115
 116 Technical (milder)
 117 ------------------
 118
 119 * merge-recursive needs to register conflicting paths as higher
 120   stage entries in the index.  For that, it first needs to
 121   construct three trees whose paths are already renamed, and
 122   call 3-way read-tree.
 123
 124 * Binary package split.  Plan laid out and discussion mostly
 125   done. [RPM side done; Debian side delegated]
 126
 127 * User-relative paths by Andreas Ericsson. [DONE]
 128
 129 * Accessing configuration variables from C and from scripts by
 130   Johannes [DONE].
 131
 132 * Proxing git:// connection by Paul Collins. [DONE]
 133
 134 * Maybe look at Cogito and see if I can help Pasky to adjust to
 135   the later core features?
 136
 137 * Perhaps detect cloning request in upload-pack and cache the
 138   result for next cloning request until any of our refs change.
 139
 140 * Encourage concrete proposals to commit log message templates
 141   we discussed some time ago.
 142
 143 * Perhaps accept patches to do undo/redo.
 144
 145 * Perhaps accept patch to optionally allow '--fuzz' in
 146   'git-apply'.
 147
 148 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 149   to say '\No newline' if both input ends with incomplete
 150   lines.
 151
 152 * Maybe grok PGP signed text/plain in applymbox as well.
 153
 154 * Enhance "git repack" to not always use --all; this would be
 155   handy if the repository contains wagging heads like "pu" in
 156   git.git repository.
 157
 158 * Make rebase restartable; instead of skipping what cannot be
 159   automatically forward ported, leave the conflicts in the work
 160   tree, have the user resolve it, and then restart from where it
 161   left off [DONE].
 162
 163 * Output full path in the "git-rev-list --objects" output, not
 164   just the basename, and see the improved clustering results in
 165   better packing [Tried, but did not work out well].
 166
 167 * Updated git-changes-script Jeff Garzik needs [Not needed --
 168   pull into local or borrow temporarily with alternate object
 169   directories environment variable and use normal tools].
 170
 171 * Customizable init-db.  Personally I think template mechanism
 172   is good enough.  Otherwise, maybe add hooks/post-init-db.
 173
 174 * Make sure we do reasonable thing on binary files even in
 175   cherry-pick and rebase [DONE].
 176
 177 * Binary diff detection fails if locale set to non English; even
 178   GNU diff 2.8.1 and 2.8.7 in C locale say different things.  At
 179   least run diff under C locale (setenv LANG=C LC_ALL=C) for
 180   1.0.  It might be better to have our own binary detection
 181   logic, or even our own diff output without forking an external
 182   diff.  [The former _might_ make sense for 1.0, but the latter
 183   is post 1.0].
 184
 185
 186 Technical (trivial)
 187 -------------------
 188
 189 * Stop installing the old-name symlinks [DONE].
 190
 191 * 'git merge-projects'?
 192
 193   Subject: Re: Merges without bases
 194   References: <1125004228.4110.20.camel@localhost.localdomain>
 195   Date: Thu, 25 Aug 2005 15:26:36 -0700
 196   Message-ID: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>
 197
 198 * 'git lost-and-found'?  Link dangling commits found by
 199   fsck-objects under $GIT_DIR/refs/lost-found/.  Then
 200   show-branch or gitk can be used to find any lost commit.
 201   [DONE]
 202
 203   Do not name it /lost+found/; that would probably confuse
 204   things that mistake it a mount point (not our code but
 205   somebody else's).
 206
 207 * Add simple globbing rules to git-show-branch so that I can
 208   say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
 209   ko-rc are in refs/tags/).
 210
 211 * We would want test scripts for the relative directory path
 212   stuff Linus has been working on.  Most of the C-level
 213   commands should be usable with relative directory paths.
 214
 215 * In a freashly created empty repository, `git fetch foo:bar`
 216   works OK, but `git checkout bar` afterwards does not (missing
 217   `.git/HEAD`).
 218
 219 \f
 220 Local Variables:
 221 mode: text
 222 End: