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