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 * "intent to add" index entries?
  31
  32 * Plug-in file-level merges.  On the other hand, we may not even
  33   need this; just tell people to run "xxdiff -U" on the working
  34   tree files.
  35
  36 * Doing a merge in a separate directory?
  37
  38 * Make 'format-patch' take revision limiters similar to
  39   rev-list.  For example:
  40
  41                A                   C
  42         ....---x---o---o---x---o---o
  43                           /
  44                          /
  45                         /
  46         ....---x---o---o
  47                B
  48
  49   we should be able to format commits 'o', without duplicates,
  50   by:
  51
  52         $ git format-patch ^A ^B C
  53
  54   Currently the closest approximation is
  55
  56         $ git format-patch A..C B..C
  57
  58   which results in the last two commits including C formatted
  59   twice.
  60
  61
  62 Technical (heavier)
  63 -------------------
  64
  65 * Libification.  There are many places "run once" mentality is
  66   ingrained in the management of basic data structures, which
  67   need to be fixed.  [Matthias Urlichs is already working on
  68   this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
  69
  70 * Maybe a pack optimizer.
  71
  72   Given a set of objects and a set of refs (probably a handful
  73   branch heads and point release tags), find a set of packs to
  74   allow reasonably minimum download for all of these classes of
  75   people: (1) somebody cloning the repository from scratch, (2)
  76   somebody who tends to follow the master branch head reasonably
  77   closely, (3) somebody who tends to follow only the point
  78   releases.
  79
  80   This needs a matching smart on the dumb protocol downloader.
  81
  82
  83 Technical (milder)
  84 ------------------
  85
  86 * Shallow clones.
  87
  88 * Encourage competition between annotate vs blame.  Maybe come
  89   up with some nontrivial test cases.
  90
  91 * Subprojects.  I think the "bind commit" approach has been
  92   outlined at sufficiently detailed level.  Maybe find time to
  93   actually start prototyping it?
  94
  95   <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
  96
  97 * Decide what to do about rebase applied to merged head.  One
  98   extreme is to allow rebase if "rev-list ours..theirs" gives
  99   anything.  This loosens the current merge-base based approach.
 100   The other extreme is to refuse rebase if "rev-list
 101   theirs..ours" contains any merge commit, which was discussed
 102   on the list.
 103
 104   <43CC695E.2020506@codeweavers.com>
 105
 106 * Decide what the right thing to do upon an empty merge commit,
 107   when both branches happen to have obtained the same set of
 108   changes through different history.  Not recording such keeps
 109   the history simpler, and the next merge would soon create a
 110   true merge commit anyway, but this does not feel quite right.
 111
 112   <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
 113
 114 * diff stopping at the first output; qgit wants to know if this
 115   tree has any A or D from the other tree and nothing else.
 116   Would help internal tree-diff in rev-list as well.
 117
 118 * daemon --strict-symlink.
 119
 120 * daemon --base-path does not apply automatically to whitelist
 121   somehow feels wrong.  If somebody cares enough, accept
 122   patches.
 123
 124 * Perhaps detect cloning request in upload-pack and cache the
 125   result for next cloning request until any of our refs change.
 126
 127 * Perhaps deal with "Files differ" (binary diff) in non C
 128   locales.
 129
 130 * Maybe grok PGP signed text/plain in applymbox as well.
 131
 132
 133 Technical (trivial)
 134 -------------------
 135
 136 * git-proxy should be spawned with sh -c 'command' $1 $2.
 137
 138 * test scripts for the relative directory path stuff.
 139
 140 * In a freshly created empty repository, `git fetch foo:bar`
 141   works OK, but `git checkout bar` afterwards does not (missing
 142   `.git/HEAD`).
 143
 144 \f
 145 Local Variables:
 146 mode: text
 147 End: