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 * Binary package split.  Plan laid out and discussion mostly
 120   done. [RPM side done; Debian side delegated]
 121
 122 * User-relative paths by Andreas Ericsson. [STILL BREWING BUT
 123   ALMOST DONE]
 124
 125 * Accessing configuration variables from C and from scripts by
 126   Johannes [STILL BREWING BUT ALMOST DONE].
 127
 128 * Proxing git:// connection by Paul Collins. [Need to ping]
 129
 130 * Maybe look at Cogito and see if I can help Pasky to adjust to
 131   the later core features?
 132
 133 * Perhaps detect cloning request in upload-pack and cache the
 134   result for next cloning request until any of our refs change.
 135
 136 * Encourage concrete proposals to commit log message templates
 137   we discussed some time ago.
 138
 139 * Perhaps accept patches to do undo/redo.
 140
 141 * Perhaps accept patch to optionally allow '--fuzz' in
 142   'git-apply'.
 143
 144 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 145   to say '\No newline' if both input ends with incomplete
 146   lines.
 147
 148 * Maybe grok PGP signed text/plain in applymbox as well.
 149
 150 * Enhance "git repack" to not always use --all; this would be
 151   handy if the repository contains wagging heads like "pu" in
 152   git.git repository.
 153
 154 * Make rebase restartable; instead of skipping what cannot be
 155   automatically forward ported, leave the conflicts in the work
 156   tree, have the user resolve it, and then restart from where it
 157   left off [mechanism DONE; in pu].
 158
 159 * Output full path in the "git-rev-list --objects" output, not
 160   just the basename, and see the improved clustering results in
 161   better packing [Tried, but did not work out well].
 162
 163 * Updated git-changes-script Jeff Garzik needs [Inquiry for
 164   external spec sent out with a quick hack.  Will know if that
 165   is what he needs hopefully soon].
 166
 167 * Customizable init-db.  Personally I think template mechanism
 168   is good enough.  Otherwise, maybe add hooks/post-init-db.
 169
 170 * Make sure we do reasonable thing on binary files even in
 171   cherry-pick and rebase. [mechanism DONE; rebase in pu]
 172
 173 * Binary diff detection fails if locale set to non English; even
 174   GNU diff 2.8.1 and 2.8.7 in C locale say different things.  At
 175   least run diff under C locale (setenv LANG=C LC_ALL=C) for
 176   1.0.  It might be better to have our own binary detection
 177   logic, or even our own diff output without forking an external
 178   diff.  [The former _might_ make sense for 1.0, but the latter
 179   is post 1.0].
 180
 181
 182 Technical (trivial)
 183 -------------------
 184
 185 * Stop installing the old-name symlinks [DONE].
 186
 187 * 'git merge-projects'?
 188
 189   Subject: Re: Merges without bases
 190   References: <1125004228.4110.20.camel@localhost.localdomain>
 191   Date: Thu, 25 Aug 2005 15:26:36 -0700
 192   Message-ID: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>
 193
 194 * 'git lost-and-found'?  Link dangling commits found by
 195   fsck-objects under $GIT_DIR/refs/lost-found/.  Then
 196   show-branch or gitk can be used to find any lost commit.
 197   [DONE]
 198
 199   Do not name it /lost+found/; that would probably confuse
 200   things that mistake it a mount point (not our code but
 201   somebody else's).
 202
 203 * Add simple globbing rules to git-show-branch so that I can
 204   say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
 205   ko-rc are in refs/tags/).
 206
 207 * We would want test scripts for the relative directory path
 208   stuff Linus has been working on.  So far, the following
 209   commands should be usable with relative directory paths:
 210
 211     git-update-index
 212     git-ls-files
 213     git-diff-files
 214     git-diff-index
 215     git-diff-tree
 216     git-rev-list
 217     git-rev-parse
 218
 219 * In a freashly created empty repository, `git fetch foo:bar`
 220   works OK, but `git checkout bar` afterwards does not (missing
 221   `.git/HEAD`).
 222
 223 \f
 224 Local Variables:
 225 mode: text
 226 End: