The GIT To-Do File ================== The latest copy of this document is found at http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO What to expect from now on ========================== This is written in a form of to-do list for me, so if I say "accept patch", it means I do not currently plan to do that myself. People interested in seeing it materialize please take a hint. Also whatever I marked "Perhaps" do not have to happen 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 ------------- * tree entries in index? * "intent to add" index entries? * 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? Technical (heavier) ------------------- * 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. * 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) ------------------ * Shallow clones. * Encourage competition between annotate vs blame. Maybe come up with some nontrivial test cases. * Subprojects. Try "gitlink". * Decide what to do about rebase applied to merged head. One extreme is to allow rebase if "rev-list ours..theirs" gives anything. This loosens the current merge-base based approach. The other extreme is to refuse rebase if "rev-list theirs..ours" contains any merge commit, which was discussed on the list. <43CC695E.2020506@codeweavers.com> * Decide what the right thing to do upon an empty merge commit, when both branches happen to have obtained the same set of changes through different history. Not recording such keeps the history simpler, and the next merge would soon create a true merge commit anyway, but this does not feel quite right. <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com> * 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. * daemon --strict-symlink. * daemon --base-path does not apply automatically to whitelist somehow feels wrong. If somebody cares enough, accept patches. * Perhaps detect cloning request in upload-pack and cache the result for next cloning request until any of our refs change. * Maybe grok PGP signed text/plain in applymbox as well. Technical (trivial) ------------------- * git-proxy should be spawned with sh -c 'command' $1 $2. * test scripts for the relative directory path stuff. * In a freshly created empty repository, `git fetch foo:bar` works OK, but `git checkout bar` afterwards does not (missing `.git/HEAD`). Local Variables: mode: text End: