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