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 Design issues
  21 -------------
  22
  23 * tree entries in index?  -- sorry, stalled
  24
  25 * "intent to add" index entries?  -- together with the above
  26   needs rethinking.
  27
  28 * Plug-in file-level merges.  On the other hand, we may not even
  29   need this; just tell people to run "xxdiff -U" on the working
  30   tree files (or kompare).
  31
  32
  33 Technical (heavier)
  34 -------------------
  35
  36 * Libification.  There are many places "run once" mentality is
  37   ingrained in the management of basic data structures, which
  38   need to be fixed.  [Matthias Urlichs was already working on
  39   this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>, but I
  40   do not know what happened to his efforts]
  41
  42 * Lazy clones that can be controlled by the user, ranging from
  43   totally on-demand a la CVS/SVN to "cache down to this old
  44   commit so that I can make full use of git on at least recent
  45   history".  This need a lot of work in making tools to exit
  46   gracefully when they hit unavailable objects while offline.
  47
  48
  49 Technical (milder)
  50 ------------------
  51
  52 * git grep should be able to omit prefix when invoked from a
  53   subdirectory.  Either make it an option or default with
  54   --full-name like ls-files does.
  55
  56 * duplicated refspec given to "fetch-pack a a a" makes it emit
  57   strange error message because it triggers the "match only
  58   once" logic.  Maybe strip the dups on the input side
  59   (Uwe Zeisberger
  60   <20060608073857.GA5072@informatik.uni-freiburg.de>).
  61
  62 * map only parts of huge packfiles and LRU fragments of them.
  63   People are starting to try git on projects with deep history
  64   and/or many objects, e.g. Mozilla.
  65
  66 * upload-pack support for start fetching from any valid point on
  67   the history, not just published refs. (Erik W. Biederman
  68   <m164jc9ekx.fsf@ebiederm.dsl.xmission.com>)
  69
  70 * git-daemon side support for virtual hosting.  Client side
  71   is ready in 1.4.0 (Jon Loeliger <1149610100.23938.75.camel@cashmere.sps.mot.com>).
  72
  73 * teach git-upload-pack not to ack-continue early when the
  74   client has roots it does not know about but it already has
  75   learned the fork points for all the requested heads
  76   (Ralf Baechle <20060524131022.GA11449@linux-mips.org>).
  77
  78 * Per user .gitconfig across repositories -- ongoing.
  79
  80 * Encourage competition between annotate vs blame.  Maybe come
  81   up with some nontrivial test cases.
  82
  83 * Subprojects.  Try "gitlink" -- sorry, stalled.
  84
  85 * Rebase and checkout -m should be able to use recursive
  86   strategy as well.  These commands currently do not work across
  87   renames.
  88
  89 * Decide what to do about rebase applied to merged head.  One
  90   extreme is to allow rebase if "rev-list ours..theirs" gives
  91   anything.  This loosens the current merge-base based approach.
  92   The other extreme is to refuse rebase if "rev-list
  93   theirs..ours" contains any merge commit, which was discussed
  94   on the list.
  95
  96   <43CC695E.2020506@codeweavers.com>
  97
  98 * Decide what the right thing to do upon an empty merge commit,
  99   when both branches happen to have obtained the same set of
 100   changes through different history.  Not recording such keeps
 101   the history simpler, and the next merge would soon create a
 102   true merge commit anyway, but this does not feel quite right.
 103
 104   <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
 105
 106 * diff stopping at the first output; qgit wants to know if this
 107   tree has any A or D from the other tree and nothing else.
 108   Would help internal tree-diff in rev-list as well.
 109
 110 * daemon --strict-symlink.
 111
 112 * daemon --base-path does not apply automatically to whitelist
 113   somehow feels wrong.  If somebody cares enough, accept
 114   patches.
 115
 116 * Perhaps detect cloning request in upload-pack and cache the
 117   result for next cloning request until any of our refs change.
 118
 119 * Maybe grok PGP signed text/plain in applymbox as well.
 120
 121
 122 Technical (trivial)
 123 -------------------
 124
 125 * git-proxy should be spawned with sh -c 'command' $1 $2.
 126
 127 * Maybe a true git-proxy command that reads the first request
 128   pkt-line, and redirects the request to its real destination.
 129
 130 * test scripts for the relative directory path stuff.
 131
 132 * In a freshly created empty repository, `git fetch foo:bar`
 133   works OK, but `git checkout bar` afterwards does not (missing
 134   `.git/HEAD`).
 135
 136 \f
 137 Local Variables:
 138 mode: text
 139 End: