From ba776ae4b85b10c278c618cada2b0caa1c50ad03 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 5 May 2006 19:12:09 -0700 Subject: [PATCH] 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. --- TODO | 43 ++++++++----------------------------------- 1 file changed, 8 insertions(+), 35 deletions(-) diff --git a/TODO b/TODO index 0d86e47d..6dc00280 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: ] - * 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: ] + 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. -- 2.11.0