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 What to expect from now on
  10 ==========================
  11
  12 This is written in a form of to-do list for me, so if I say
  13 "accept patch", it means I do not currently plan to do that
  14 myself.  People interested in seeing it materialize please take
  15 a hint.  Also whatever I marked "Perhaps" do not have to happen
  16 if ever -- only if somebody cares enough and submits a clean
  17 patch, perhaps ;-).
  18
  19
  20 Documentation
  21 -------------
  22
  23 * No pending issues at the moment.  "Revamp Tutorial" initiative
  24   by Bruce Fields ongoing and things are looking better.
  25
  26
  27 Design issues
  28 -------------
  29
  30 * Rehash "git commit" with various parameters to be more
  31   intuitive without breaking traditinal users too much.  We need
  32   to phase this in, especially if we are going to change "git
  33   commit" to imply the current "git commit -a" behaviour.
  34
  35 * "intent to add" index entries.
  36
  37 * Plug-in file-level merges.  On the other hand, we may not even
  38   need this; just tell people to run "xxdiff -U" on the working
  39   tree files.
  40
  41 * Doing a merge in a separate directory.
  42
  43 * Make 'format-patch' take revision limiters similar to
  44   rev-list.  For example:
  45
  46                A                   C
  47         ....---x---o---o---x---o---o
  48                           /
  49                          /
  50                         /
  51         ....---x---o---o
  52                B
  53
  54   we should be able to format commits 'o', without duplicates,
  55   by:
  56
  57         $ git format-patch ^A ^B C
  58
  59   Currently the closest approximation is
  60
  61         $ git format-patch A..C B..C
  62
  63   which results in the last two commits including C formatted
  64   twice.
  65
  66
  67 Technical (heavier)
  68 -------------------
  69
  70 * Libification.  There are many places "run once" mentality is
  71   ingrained in the management of basic data structures, which
  72   need to be fixed.  [Matthias Urlichs is already working on
  73   this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
  74
  75 * Maybe a pack optimizer.
  76
  77   Given a set of objects and a set of refs (probably a handful
  78   branch heads and point release tags), find a set of packs to
  79   allow reasonably minimum download for all of these classes of
  80   people: (1) somebody cloning the repository from scratch, (2)
  81   somebody who tends to follow the master branch head reasonably
  82   closely, (3) somebody who tends to follow only the point
  83   releases.
  84
  85   This needs a matching smart on the dumb protocol downloader.
  86
  87 * Maybe an Emacs VC backend.
  88
  89 * Look at libified GNU diff CVS seems to use, or libxdiff.
  90   [Daniel has his own diff tool almost ready to start
  91   integrating and testing]
  92
  93
  94 Technical (milder)
  95 ------------------
  96
  97 * "git status -v" to give commit preview.
  98
  99 * Subprojects.  I think the "bind commit" approach has been
 100   outlined at sufficiently detailed level.  Maybe find time to
 101   actually start prototyping it?
 102
 103   <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
 104
 105 * Shallow clones.
 106
 107 * Mark entries as "assume unchanged" in the index.
 108
 109   <Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>
 110
 111   A config item '[core] trust_stat = false' would cause to:
 112
 113   - "update-index" with or without --add would mark the path
 114     valid after registering.  Should we make the working tree
 115     file read-only at this point?
 116
 117   - checkout-index -u would mark the path and makes the working
 118     tree file read-only.
 119
 120   - read-tree without -u would mark the path invalid.
 121
 122   - update-index --refresh should *not* mark up-to-date paths valid.
 123
 124   Impacts to various commands:
 125
 126   - update-index --refresh would ignore them.
 127
 128   - diff-files would say unchanged.
 129
 130   - diff-index without --cached acts the same way as diff-index
 131     --cached.
 132
 133 * Decide what to do about rebase applied to merged head.  One
 134   extreme is to allow rebase if "rev-list ours..theirs" gives
 135   anything.  This loosens the current merge-base based approach.
 136   The other extreme is to refuse rebase if "rev-list
 137   theirs..ours" contains any merge commit, which was discussed
 138   on the list.
 139
 140   <43CC695E.2020506@codeweavers.com>
 141
 142 * Decide what the right thing to do upon an empty merge commit,
 143   when both branches happen to have obtained the same set of
 144   changes through different history.  Not recording such keeps
 145   the history simpler, and the next merge would soon create a
 146   true merge commit anyway, but this does not feel quite right.
 147
 148   <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
 149
 150 * Perhaps a smarter HTTP anonymous download via CGI.
 151
 152 * diff stopping at the first output; qgit wants to know if this
 153   tree has any A or D from the other tree and nothing else.
 154   Would help internal tree-diff in rev-list as well.
 155
 156 * daemon --strict-symlink.
 157
 158 * daemon --base-path does not apply automatically to whitelist
 159   somehow feels wrong.  If somebody cares enough, accept
 160   patches.
 161
 162 * Perhaps detect cloning request in upload-pack and cache the
 163   result for next cloning request until any of our refs change.
 164
 165 * Perhaps accept patch to optionally allow '--fuzz' in
 166   'git-apply'.  am/applymbox is _not_ the place to do it.
 167
 168 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 169   to say '\No newline' if both input ends with incomplete
 170   lines.
 171
 172 * Perhaps deal with "Files differ" (binary diff) in non C
 173   locales.
 174
 175 * Maybe grok PGP signed text/plain in applymbox as well.
 176
 177 * Output full path in the "git-rev-list --objects" output, not
 178   just the basename, and see the improved clustering results in
 179   better packing [Tried, but did not work out well].
 180
 181
 182 Technical (trivial)
 183 -------------------
 184
 185 * git-proxy should be spawned with sh -c 'command' $1 $2.
 186
 187 * test scripts for the relative directory path stuff.
 188
 189 * In a freshly created empty repository, `git fetch foo:bar`
 190   works OK, but `git checkout bar` afterwards does not (missing
 191   `.git/HEAD`).
 192
 193 \f
 194 Local Variables:
 195 mode: text
 196 End: