X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=TODO;h=027c4bc8184cd99f300df15aceea1796efbae135;hb=53b13cb673f59b6d192c8a38671c00826e37b08e;hp=a38f6ebe476a92daf55857e0f00d48c9291e964e;hpb=1d0a93105b2b2f6821e2b13a88869bad1a2358f9;p=git.git diff --git a/TODO b/TODO index a38f6ebe..027c4bc8 100644 --- a/TODO +++ b/TODO @@ -17,51 +17,17 @@ if ever -- only if somebody cares enough and submits a clean patch, perhaps ;-). -Documentation -------------- - -* No pending issues at the moment. "Revamp Tutorial" initiative - by Bruce Fields ongoing and things are looking better. - - Design issues ------------- -* Rehash "git commit" with various parameters to be more - intuitive without breaking traditinal users too much. We need - to phase this in, especially if we are going to change "git - commit" to imply the current "git commit -a" behaviour. +* tree entries in index? -- sorry, stalled -* "intent to add" index entries. +* "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) @@ -69,66 +35,48 @@ 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 - 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. - - This needs a matching smart on the dumb protocol downloader. + need to be fixed. [Matthias Urlichs was already working on + this: , but I + do not know what happened to his efforts] -* Maybe an Emacs VC backend. - -* Look at libified GNU diff CVS seems to use, or libxdiff. - [Daniel has his own diff tool almost ready to start - integrating and testing] +* 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) ------------------ -* "git status -v" to give commit preview. - -* Subprojects. I think the "bind commit" approach has been - outlined at sufficiently detailed level. Maybe find time to - actually start prototyping it? - - <7vacdzkww3.fsf@assigned-by-dhcp.cox.net> - -* Shallow clones. - -* Mark entries as "assume unchanged" in the index. - - - - A config item '[core] trust_stat = false' would cause to: +* 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>). - - "update-index" with or without --add would mark the path - valid after registering. Should we make the working tree - file read-only at this point? +* upload-pack support for start fetching from any valid point on + the history, not just published refs. (Erik W. Biederman + ) - - checkout-index -u would mark the path and makes the working - tree file read-only. +* 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>). - - read-tree without -u would mark the path invalid. +* 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>). - - update-index --refresh should *not* mark up-to-date paths valid. +* Per user .gitconfig across repositories -- ongoing. - Impacts to various commands: +* Encourage competition between annotate vs blame. Maybe come + up with some nontrivial test cases. - - update-index --refresh would ignore them. +* Subprojects. Try "gitlink" -- sorry, stalled. - - diff-files would say unchanged. - - - diff-index without --cached acts the same way as diff-index - --cached. +* 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 @@ -147,8 +95,6 @@ Technical (milder) <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com> -* Perhaps a smarter HTTP anonymous download via CGI. - * diff stopping at the first output; qgit wants to know if this tree has any A or D from the other tree and nothing else. Would help internal tree-diff in rev-list as well. @@ -162,28 +108,17 @@ Technical (milder) * Perhaps detect cloning request in upload-pack and cache the result for next cloning request until any of our refs change. -* Perhaps accept patch to optionally allow '--fuzz' in - 'git-apply'. am/applymbox is _not_ the place to do it. - -* Allow 'git apply' to accept GNU diff 2.7 output that forgets - to say '\No newline' if both input ends with incomplete - lines. - -* Perhaps deal with "Files differ" (binary diff) in non C - locales. - * Maybe grok PGP signed text/plain in applymbox as well. -* Output full path in the "git-rev-list --objects" output, not - just the basename, and see the improved clustering results in - better packing [Tried, but did not work out well]. - 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`