Minor update to Subpro.txt
[git.git] / TODO
diff --git a/TODO b/TODO
index cc4dc34..0d86e47 100644 (file)
--- a/TODO
+++ b/TODO
-What to expect after 0.99.5
-===========================
+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.
+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 ;-).
 
 
-Documentation
+UI
+--
+
+* Make "git branch -d foo" while on foo branch suggest "maybe
+  you want to go back to 'master'?"
+
+
+Design issues
 -------------
 
-* Accept patches from people who actually have done CVS
-  migration and update the cvs-migration documentation.
-  Link the documentation from the main git.txt page.
+* "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.
 
-* Link howto docs from the git.txt page. [DONE]
+* Doing a merge in a separate directory?
 
-* Update the SubmittingPatches document to add MUA specific
-  hints on how to disable unwanted MIME and flowed-text by
-  collecting past list postings.  Accept patches from people who
-  was hit by shiny blue bat to update the same.
+* Make 'format-patch' take revision limiters similar to
+  rev-list.  For example:
 
-* Talk about using rsync just once at the beginning when
-  initializing a remote repository so that local packs do not
-  need to be expanded.  I personally do not think we need tool
-  support for this.
+               A                  C
+       ....---x---o---o---x---o---o
+                          /
+                         /
+                        /
+       ....---x---o---o
+               B
 
-* Update tutorial to cover shared repository style a bit more,
-  maybe with a toy project that involves two or three
-  repositories.
+  we should be able to format commits 'o', without duplicates,
+  by:
 
-* Update tutorial to cover setting up repository hooks to do
-  common tasks.
+       $ git format-patch ^A ^B C
 
-* Get help to properly use asciidoc in tutorial.
+  Currently the closest approximation is
 
-* Maybe justify and demonstrate an Octopus in the tutorial.  Add
-  it to the glossary.
+       $ git format-patch A..C B..C
+
+  which results in the last two commits including C formatted
+  twice.
 
 
 Technical (heavier)
 -------------------
 
-* Tony Luck reported an unfortunate glitch in the 3-way merge.
-  Encourage discussions to come up with a not-so-expensive way
-  to catch the kind of ambiguities that led to his misery.
+* 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: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>]
+
+* 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.
 
 
 Technical (milder)
 ------------------
 
-* When the branch head pointed by $GIT_DIR/HEAD changes while
-  the index file and working tree are looking the other way
-  (e.g. somebody pushed into your repository, or you ran "git
-  fetch" to update the ref your working tree is on), "git
-  checkout" without -f gets confused.  Figure out a good way to
-  handle this. [DONE - waiting for response]
+* Shallow clones.
 
-* "git commit -m" should work for initial commits and perhaps
-  merge commits as well.  Warning about merge is still a good
-  thing to do, while -m is useful in scripted non-interactive
-  use, so we need to be careful. [DONE - waiting for response]
+* Encourage competition between annotate vs blame.  Maybe come
+  up with some nontrivial test cases.
 
-* Encourage concrete proposals to commit log message templates
-  we discussed some time ago.
+* Subprojects.  I think the "bind commit" approach has been
+  outlined at sufficiently detailed level.  Maybe find time to
+  actually start prototyping it?
 
-* Bug Ryan and work with him to update send-email easier to use.
+  <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
 
-* Look at portability fixes from Jason Riedy
+* 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.
 
-    http://www.cs.berkeley.edu/~ejr/gits/git.git#portable 
+  <43CC695E.2020506@codeweavers.com>
 
-  [Looked at it.  Maybe promising.  Maybe not.]
+* 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.
 
-* Accept patches to cause "read-tree -u" delete a directory when
-  it makes it empty.
+  <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
 
-* Perhaps accept patches to introduce the concept of "patch flow
-  expressed as ref mappings" Josef has been advocating about.
+* 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.
 
-* Perhaps accept patches to do undo/redo, but I am reluctant to
-  add commands to cover very limited use cases right now.
+* daemon --strict-symlink.
 
-* MIMEified applymbox to grok B and Q encodings in headers and
-  turn them into UTF-8; unwrap QP; explode multipart.
+* daemon --base-path does not apply automatically to whitelist
+  somehow feels wrong.  If somebody cares enough, accept
+  patches.
 
-* "git cherry-pick" that applies the patch an existing commit
-  introduces in its ancestry chain, possibly using the 3-way
-  merge machinery; update rebase using the cherry-pick command.
-  Carl's redo/undo might fall out naturally from this.
+* Perhaps detect cloning request in upload-pack and cache the
+  result for next cloning request until any of our refs change.
 
-* Redo "git revert" using 3-way merge machinery. [Done.]
+* Perhaps deal with "Files differ" (binary diff) in non C
+  locales.
+
+* Maybe grok PGP signed text/plain in applymbox as well.
+
+
+Technical (trivial)
+-------------------
 
-* A tool to detect, show and prune already merged topic
-  branches.
+* git-proxy should be spawned with sh -c 'command' $1 $2.
 
-* Perhaps "git branch -d" to delete a branch.
+* test scripts for the relative directory path stuff.
 
-* Enhance "git repack" to not always use --all; this would be
-  handy if the repository contains wagging heads like "pu" in
-  git.git repository.
+* In a freshly created empty repository, `git fetch foo:bar`
+  works OK, but `git checkout bar` afterwards does not (missing
+  `.git/HEAD`).
 
-* Remove "git clone-dumb-http".
+\f
+Local Variables:
+mode: text
+End: