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