TODO updates (remove stale ones)

Pasky twisted my arm so I started to look at how stale my TODO
list was.  I'll move some stuff from the "unresolved" posting
after rethinking, but for now this removes the old or resolved
entries first.

diff --git a/TODO b/TODO
index 0d86e47..6dc0028 100644 (file)
--- 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.