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 UI
  21 --
  22
  23 * Make "git branch -d foo" while on foo branch suggest "maybe
  24   you want to go back to 'master'?"
  25
  26
  27 Design issues
  28 -------------
  29
  30 * tree entries in index?
  31
  32 * "intent to add" index entries?
  33
  34 * Plug-in file-level merges.  On the other hand, we may not even
  35   need this; just tell people to run "xxdiff -U" on the working
  36   tree files.
  37
  38 * Doing a merge in a separate directory?
  39
  40
  41 Technical (heavier)
  42 -------------------
  43
  44 * Maybe a pack optimizer.
  45
  46   Given a set of objects and a set of refs (probably a handful
  47   branch heads and point release tags), find a set of packs to
  48   allow reasonably minimum download for all of these classes of
  49   people: (1) somebody cloning the repository from scratch, (2)
  50   somebody who tends to follow the master branch head reasonably
  51   closely, (3) somebody who tends to follow only the point
  52   releases.
  53
  54   This needs a matching smart on the dumb protocol downloader.
  55
  56 * Libification.  There are many places "run once" mentality is
  57   ingrained in the management of basic data structures, which
  58   need to be fixed.  [Matthias Urlichs is already working on
  59   this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
  60
  61
  62 Technical (milder)
  63 ------------------
  64
  65 * Shallow clones.
  66
  67 * Encourage competition between annotate vs blame.  Maybe come
  68   up with some nontrivial test cases.
  69
  70 * Subprojects.  Try "gitlink".
  71
  72
  73 * Decide what to do about rebase applied to merged head.  One
  74   extreme is to allow rebase if "rev-list ours..theirs" gives
  75   anything.  This loosens the current merge-base based approach.
  76   The other extreme is to refuse rebase if "rev-list
  77   theirs..ours" contains any merge commit, which was discussed
  78   on the list.
  79
  80   <43CC695E.2020506@codeweavers.com>
  81
  82 * Decide what the right thing to do upon an empty merge commit,
  83   when both branches happen to have obtained the same set of
  84   changes through different history.  Not recording such keeps
  85   the history simpler, and the next merge would soon create a
  86   true merge commit anyway, but this does not feel quite right.
  87
  88   <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
  89
  90 * diff stopping at the first output; qgit wants to know if this
  91   tree has any A or D from the other tree and nothing else.
  92   Would help internal tree-diff in rev-list as well.
  93
  94 * daemon --strict-symlink.
  95
  96 * daemon --base-path does not apply automatically to whitelist
  97   somehow feels wrong.  If somebody cares enough, accept
  98   patches.
  99
 100 * Perhaps detect cloning request in upload-pack and cache the
 101   result for next cloning request until any of our refs change.
 102
 103 * Maybe grok PGP signed text/plain in applymbox as well.
 104
 105
 106 Technical (trivial)
 107 -------------------
 108
 109 * git-proxy should be spawned with sh -c 'command' $1 $2.
 110
 111 * test scripts for the relative directory path stuff.
 112
 113 * In a freshly created empty repository, `git fetch foo:bar`
 114   works OK, but `git checkout bar` afterwards does not (missing
 115   `.git/HEAD`).
 116
 117 \f
 118 Local Variables:
 119 mode: text
 120 End: