diff --git a/TODO b/TODO
index 0d86e47d6c..6dc00280a4 100644
--- a/TODO
+++ b/TODO
@@ -27,6 +27,8 @@ UI
 Design issues
 -------------
 
+* tree entries in index?
+
 * "intent to add" index entries?
 
 * Plug-in file-level merges.  On the other hand, we may not even
@@ -35,38 +37,10 @@ Design issues
 
 * Doing a merge in a separate directory?
 
-* Make 'format-patch' take revision limiters similar to
-  rev-list.  For example:
-
-               A		   C
-	....---x---o---o---x---o---o
-                          /
-                         /
-                        /
-	....---x---o---o
-               B
-
-  we should be able to format commits 'o', without duplicates,
-  by:
-
-  	$ git format-patch ^A ^B C
-
-  Currently the closest approximation is
-
-  	$ git format-patch A..C B..C
-
-  which results in the last two commits including C formatted
-  twice.
-
 
 Technical (heavier)
 -------------------
 
-* Libification.  There are many places "run once" mentality is
-  ingrained in the management of basic data structures, which
-  need to be fixed.  [Matthias Urlichs is already working on
-  this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
-
 * Maybe a pack optimizer.
 
   Given a set of objects and a set of refs (probably a handful
@@ -79,6 +53,11 @@ Technical (heavier)
 
   This needs a matching smart on the dumb protocol downloader.
 
+* Libification.  There are many places "run once" mentality is
+  ingrained in the management of basic data structures, which
+  need to be fixed.  [Matthias Urlichs is already working on
+  this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
+
 
 Technical (milder)
 ------------------
@@ -88,11 +67,8 @@ Technical (milder)
 * Encourage competition between annotate vs blame.  Maybe come
   up with some nontrivial test cases.
 
-* Subprojects.  I think the "bind commit" approach has been
-  outlined at sufficiently detailed level.  Maybe find time to
-  actually start prototyping it?
+* Subprojects.  Try "gitlink".
 
-  <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
 
 * Decide what to do about rebase applied to merged head.  One
   extreme is to allow rebase if "rev-list ours..theirs" gives
@@ -124,9 +100,6 @@ Technical (milder)
 * Perhaps detect cloning request in upload-pack and cache the
   result for next cloning request until any of our refs change.
 
-* Perhaps deal with "Files differ" (binary diff) in non C
-  locales.
-
 * Maybe grok PGP signed text/plain in applymbox as well.