A few more items to TODO.
[git.git] / TODO
diff --git a/TODO b/TODO
index 0d86e47..9f976cf 100644 (file)
--- a/TODO
+++ b/TODO
@@ -17,46 +17,17 @@ if ever -- only if somebody cares enough and submits a clean
 patch, perhaps ;-).
 
 
-UI
---
-
-* Make "git branch -d foo" while on foo branch suggest "maybe
-  you want to go back to 'master'?"
-
-
 Design issues
 -------------
 
-* "intent to add" index entries?
+* tree entries in index?  -- sorry, stalled
+
+* "intent to add" index entries?  -- together with the above
+  needs rethinking.
 
 * Plug-in file-level merges.  On the other hand, we may not even
   need this; just tell people to run "xxdiff -U" on the working
-  tree files.
-
-* 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.
+  tree files (or kompare).
 
 
 Technical (heavier)
@@ -64,35 +35,56 @@ 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
-  branch heads and point release tags), find a set of packs to
-  allow reasonably minimum download for all of these classes of
-  people: (1) somebody cloning the repository from scratch, (2)
-  somebody who tends to follow the master branch head reasonably
-  closely, (3) somebody who tends to follow only the point
-  releases.
+  need to be fixed.  [Matthias Urlichs was already working on
+  this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>, but I
+  do not know what happened to his efforts]
 
-  This needs a matching smart on the dumb protocol downloader.
+* Lazy clones that can be controlled by the user, ranging from
+  totally on-demand a la CVS/SVN to "cache down to this old
+  commit so that I can make full use of git on at least recent
+  history".  This need a lot of work in making tools to exit
+  gracefully when they hit unavailable objects while offline.
 
 
 Technical (milder)
 ------------------
 
-* Shallow clones.
+* git grep should be able to omit prefix when invoked from a
+  subdirectory.  Either make it an option or default with
+  --full-name like ls-files does.
+
+* duplicated refspec given to "fetch-pack a a a" makes it emit
+  strange error message because it triggers the "match only
+  once" logic.  Maybe strip the dups on the input side
+  (Uwe Zeisberger
+  <20060608073857.GA5072@informatik.uni-freiburg.de>). 
+
+* map only parts of huge packfiles and LRU fragments of them.
+  People are starting to try git on projects with deep history
+  and/or many objects, e.g. Mozilla.
+
+* upload-pack support for start fetching from any valid point on
+  the history, not just published refs. (Erik W. Biederman
+  <m164jc9ekx.fsf@ebiederm.dsl.xmission.com>)
+
+* git-daemon side support for virtual hosting.  Client side
+  is ready in 1.4.0 (Jon Loeliger <1149610100.23938.75.camel@cashmere.sps.mot.com>).
+
+* teach git-upload-pack not to ack-continue early when the
+  client has roots it does not know about but it already has
+  learned the fork points for all the requested heads
+  (Ralf Baechle <20060524131022.GA11449@linux-mips.org>).
+
+* Per user .gitconfig across repositories -- ongoing.
 
 * 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" -- sorry, stalled.
 
-  <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
+* Rebase and checkout -m should be able to use recursive
+  strategy as well.  These commands currently do not work across
+  renames.
 
 * Decide what to do about rebase applied to merged head.  One
   extreme is to allow rebase if "rev-list ours..theirs" gives
@@ -124,9 +116,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.
 
 
@@ -135,6 +124,9 @@ Technical (trivial)
 
 * git-proxy should be spawned with sh -c 'command' $1 $2.
 
+* Maybe a true git-proxy command that reads the first request
+  pkt-line, and redirects the request to its real destination.
+
 * test scripts for the relative directory path stuff.
 
 * In a freshly created empty repository, `git fetch foo:bar`