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  - In 0.99.8, we will still install the backward compatible
  13    symbolic links in $(bindir).  These will however be removed
  14    before 1.0 happens.
  15
  16    git-ssh-push and git-ssh-pull pair is not going away within
  17    this timeframe, if ever.  Each of these old-name commands
  18    continues to invoke its old-name counterpart on the other
  19    end.
  20
  21
  22 What to expect after 0.99.8
  23 ===========================
  24
  25 This is written in a form of to-do list for me, so if I say
  26 "accept patch", it means I do not currently plan to do that
  27 myself.  People interested in seeing it materialize please take
  28 a hint.
  29
  30
  31 Documentation
  32 -------------
  33
  34 * Accept patches from people who actually have done CVS
  35   migration and update the cvs-migration documentation.
  36   Link the documentation from the main git.txt page.
  37
  38 * Talk about using rsync just once at the beginning when
  39   initializing a remote repository so that local packs do not
  40   need to be expanded.  I personally do not think we need tool
  41   support for this (but see below about optimized cloning).
  42
  43 * Maybe update tutorial with a toy project that involves two or
  44   three developers..
  45
  46 * Update tutorial to cover setting up repository hooks to do
  47   common tasks.
  48
  49 * Accept patches to finish missing docs.
  50
  51 * Accept patches to talk about "Whoops, it broke.  What's
  52   next?".
  53
  54 * Accept patches to make formatted tables in asciidoc to work
  55   well in both html and man pages (see git-diff(1)).
  56
  57
  58 Technical (heavier)
  59 -------------------
  60
  61 * We might want to optimize cloning with GIT native transport
  62   not to explode the pack, and store it in objects/pack instead.
  63   We would need a tool to generate an idx file out of a pack
  64   file for this.  Also this itself may turn out to be a bad
  65   idea, making the set of packs in repositories everybody has
  66   different from each other.
  67
  68 * Git daemon, when deployed at kernel.org, might turn out to be
  69   quite a burden, since it needs to generate customized packs
  70   every time a new request comes in.  It may be worthwhile to
  71   precompute some packs for popular sets of heads downloaders
  72   have and serve that, even if that could give more than the
  73   client asks for in some cases.  We will know about this soon
  74   enough.
  75
  76 * Libification.  There are many places "run once" mentality is
  77   ingrained in the management of basic data structures, which
  78   need to be fixed.
  79
  80 * Maybe a pack optimizer.
  81
  82     Given a set of objects and a set of refs (probably a handful
  83     branch heads and point release tags), find a set of packs to
  84     allow reasonably minimum download for all of these classes of
  85     people: (1) somebody cloning the repository from scratch, (2)
  86     somebody who tends to follow the master branch head reasonably
  87     closely, (3) somebody who tends to follow only the point
  88     releases.
  89
  90 * Maybe an Emacs VC backend.
  91
  92 * 'git split-projects'?  This requires updated 'git-rev-list' to
  93   skip irrelevant commits.
  94   Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>
  95
  96 * Look at libified GNU diff CVS seems to use, or libxdiff.
  97
  98
  99 Technical (milder)
 100 ------------------
 101
 102 * Encourage concrete proposals to commit log message templates
 103   we discussed some time ago.
 104
 105 * Accept patches to cause "read-tree -u" delete a directory when
 106   it makes it empty.
 107
 108 * Perhaps accept patches to introduce the concept of "patch flow
 109   expressed as ref mappings" Josef has been advocating about.
 110
 111 * Perhaps accept patches to do undo/redo.
 112
 113 * Perhaps accept patch to optionally allow '--fuzz' in
 114   'git-apply'.
 115
 116 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 117   to say '\No newline' if both input ends with incomplete
 118   lines.
 119
 120 * Maybe grok PGP signed text/plain in applymbox as well.
 121
 122 * Perhaps a tool to revert a single file to pre-modification
 123   state?  People with BK background know this operation as
 124   'clean'.  'git checkout [-f] ent [path...]' was suggested by
 125   Matthias Urlichs which sounds a natural extention to what the
 126   command currently does.
 127
 128 * Enhance "git repack" to not always use --all; this would be
 129   handy if the repository contains wagging heads like "pu" in
 130   git.git repository.
 131
 132 * Internally split the project into non-doc and doc parts; add
 133   an extra root for the doc part and merge from it; move the
 134   internal doc source to a separate repository, like the +Meta
 135   repository; experiment if this results in a reasonable
 136   workflow, and document it in howto form if it does.
 137
 138   The point is to make it possible to fork that part off to
 139   somebody else; then I do not have to maintain Documentation
 140   directory myself anymore, just like I simply slurp the latest
 141   gitk from Paul and not worry about it ;-).
 142
 143
 144 * Make rebase restartable; instead of skipping what cannot be
 145   automatically forward ported, leave the conflicts in the work
 146   tree, have the user resolve it, and then restart from where it
 147   left off.
 148
 149 * Output full path in the "git-rev-list --objects" output, not
 150   just the basename, and see the improved clustering results in
 151   better packing [Tried, but did not work out well].
 152
 153 * Updated git-changes-script Jeff Garzik needs [Inquiry for
 154   external spec sent out with a quick hack.  Will know if that
 155   is what he needs soon enough].
 156
 157
 158 Technical (trivial)
 159 -------------------
 160
 161 * short SHA1 naming is not enforcing uniqueness.  Should fix [DONE].
 162
 163 * 'git repack' can be DOSed.  Should fix [DONE].
 164
 165 * Stop installing the old-name symlinks [POSTPONED].
 166
 167 * 'git merge-projects'?
 168
 169   Subject: Re: Merges without bases
 170   References: <1125004228.4110.20.camel@localhost.localdomain>
 171   Date: Thu, 25 Aug 2005 15:26:36 -0700
 172   Message-ID: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>
 173
 174 * 'git lost-and-found'?  Link dangling commits found by
 175   fsck-objects under $GIT_DIR/refs/lost-found/.  Then
 176   show-branch or gitk can be used to find any lost commit. [A
 177   feeler patch sent out. Very underwhelming response X-<.]
 178
 179   Do not name it /lost+found/; that would probably confuse
 180   things that mistake it a mount point (not our code but
 181   somebody else's).
 182
 183 * Add simple globbing rules to git-show-branch so that I can
 184   say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
 185   ko-rc are in refs/tags/).
 186
 187 * We would want test scripts for the relative directory path
 188   stuff Linus has been working on.  So far, the following
 189   commands should be usable with relative directory paths:
 190
 191     git-update-index
 192     git-ls-files
 193     git-diff-files
 194     git-diff-index
 195     git-diff-tree
 196     git-rev-list
 197     git-rev-parse
 198
 199 * In a freashly created empty repository, `git fetch foo:bar`
 200   works OK, but `git checkout bar` afterwards does not (missing
 201   `.git/HEAD`).
 202
 203 \f
 204 Local Variables:
 205 mode: text
 206 End: