4 The latest copy of this document is found at
6 http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
9 What to expect from now on
10 ==========================
12 This is written in a form of to-do list for me, so if I say
13 "accept patch", it means I do not currently plan to do that
14 myself. People interested in seeing it materialize please take
15 a hint. Also whatever I marked "Perhaps" do not have to happen
16 if ever -- only if somebody cares enough and submits a clean
23 * Make "git branch -d foo" while on foo branch suggest "maybe
24 you want to go back to 'master'?"
30 * "intent to add" index entries?
32 * Plug-in file-level merges. On the other hand, we may not even
33 need this; just tell people to run "xxdiff -U" on the working
36 * Doing a merge in a separate directory?
38 * Make 'format-patch' take revision limiters similar to
39 rev-list. For example:
42 ....---x---o---o---x---o---o
49 we should be able to format commits 'o', without duplicates,
52 $ git format-patch ^A ^B C
54 Currently the closest approximation is
56 $ git format-patch A..C B..C
58 which results in the last two commits including C formatted
65 * Libification. There are many places "run once" mentality is
66 ingrained in the management of basic data structures, which
67 need to be fixed. [Matthias Urlichs is already working on
68 this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
70 * Maybe a pack optimizer.
72 Given a set of objects and a set of refs (probably a handful
73 branch heads and point release tags), find a set of packs to
74 allow reasonably minimum download for all of these classes of
75 people: (1) somebody cloning the repository from scratch, (2)
76 somebody who tends to follow the master branch head reasonably
77 closely, (3) somebody who tends to follow only the point
80 This needs a matching smart on the dumb protocol downloader.
88 * Encourage competition between annotate vs blame. Maybe come
89 up with some nontrivial test cases.
91 * Subprojects. I think the "bind commit" approach has been
92 outlined at sufficiently detailed level. Maybe find time to
93 actually start prototyping it?
95 <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
97 * Decide what to do about rebase applied to merged head. One
98 extreme is to allow rebase if "rev-list ours..theirs" gives
99 anything. This loosens the current merge-base based approach.
100 The other extreme is to refuse rebase if "rev-list
101 theirs..ours" contains any merge commit, which was discussed
104 <43CC695E.2020506@codeweavers.com>
106 * Decide what the right thing to do upon an empty merge commit,
107 when both branches happen to have obtained the same set of
108 changes through different history. Not recording such keeps
109 the history simpler, and the next merge would soon create a
110 true merge commit anyway, but this does not feel quite right.
112 <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
114 * diff stopping at the first output; qgit wants to know if this
115 tree has any A or D from the other tree and nothing else.
116 Would help internal tree-diff in rev-list as well.
118 * daemon --strict-symlink.
120 * daemon --base-path does not apply automatically to whitelist
121 somehow feels wrong. If somebody cares enough, accept
124 * Perhaps detect cloning request in upload-pack and cache the
125 result for next cloning request until any of our refs change.
127 * Perhaps deal with "Files differ" (binary diff) in non C
130 * Maybe grok PGP signed text/plain in applymbox as well.
136 * git-proxy should be spawned with sh -c 'command' $1 $2.
138 * test scripts for the relative directory path stuff.
140 * In a freshly created empty repository, `git fetch foo:bar`
141 works OK, but `git checkout bar` afterwards does not (missing