From: Junio C Hamano Date: Sat, 6 May 2006 02:12:09 +0000 (-0700) Subject: TODO updates (remove stale ones) X-Git-Url: https://git.octo.it/?a=commitdiff_plain;ds=sidebyside;h=ba776ae4b85b10c278c618cada2b0caa1c50ad03;p=git.git 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 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.