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 * Maybe look at Cogito and see if I can help Pasky to adjust to
 119   the later core features?  Zack Brown's "cg-seek leaving empty
 120   directories" problem is a good example of this.
 121
 122 * Perhaps detect cloning request in upload-pack and cache the
 123   result for next cloning request until any of our refs change.
 124
 125 * Encourage concrete proposals to commit log message templates
 126   we discussed some time ago.
 127
 128 * Perhaps accept patches to do undo/redo.
 129
 130 * Perhaps accept patch to optionally allow '--fuzz' in
 131   'git-apply'.
 132
 133 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 134   to say '\No newline' if both input ends with incomplete
 135   lines.
 136
 137 * Maybe grok PGP signed text/plain in applymbox as well.
 138
 139 * Enhance "git repack" to not always use --all; this would be
 140   handy if the repository contains wagging heads like "pu" in
 141   git.git repository.
 142
 143 * Make rebase restartable; instead of skipping what cannot be
 144   automatically forward ported, leave the conflicts in the work
 145   tree, have the user resolve it, and then restart from where it
 146   left off [mechanism mostly done].
 147
 148 * Output full path in the "git-rev-list --objects" output, not
 149   just the basename, and see the improved clustering results in
 150   better packing [Tried, but did not work out well].
 151
 152 * Updated git-changes-script Jeff Garzik needs [Inquiry for
 153   external spec sent out with a quick hack.  Will know if that
 154   is what he needs hopefully soon].
 155
 156 * Make sure we do reasonable thing on binary files even in
 157   cherry-pick and rebase.
 158
 159
 160 Technical (trivial)
 161 -------------------
 162
 163 * Stop installing the old-name symlinks [DONE].
 164
 165 * 'git merge-projects'?
 166
 167   Subject: Re: Merges without bases
 168   References: <1125004228.4110.20.camel@localhost.localdomain>
 169   Date: Thu, 25 Aug 2005 15:26:36 -0700
 170   Message-ID: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>
 171
 172 * 'git lost-and-found'?  Link dangling commits found by
 173   fsck-objects under $GIT_DIR/refs/lost-found/.  Then
 174   show-branch or gitk can be used to find any lost commit. [A
 175   feeler patch sent out. Very underwhelming response X-<.]
 176
 177   Do not name it /lost+found/; that would probably confuse
 178   things that mistake it a mount point (not our code but
 179   somebody else's).
 180
 181 * Add simple globbing rules to git-show-branch so that I can
 182   say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
 183   ko-rc are in refs/tags/).
 184
 185 * We would want test scripts for the relative directory path
 186   stuff Linus has been working on.  So far, the following
 187   commands should be usable with relative directory paths:
 188
 189     git-update-index
 190     git-ls-files
 191     git-diff-files
 192     git-diff-index
 193     git-diff-tree
 194     git-rev-list
 195     git-rev-parse
 196
 197 * In a freashly created empty repository, `git fetch foo:bar`
 198   works OK, but `git checkout bar` afterwards does not (missing
 199   `.git/HEAD`).
 200
 201 \f
 202 Local Variables:
 203 mode: text
 204 End: