Updates 2005-10-10
[git.git] / TODO
diff --git a/TODO b/TODO
index 25f9393..7c7f46d 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,64 +1,68 @@
-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
+
+
+Tool Renames Plan
+=================
+
+ - In 0.99.8, we will still install the backward compatible
+   symbolic links in $(bindir).  These will however be removed
+   before 1.0 happens.
+
+   git-ssh-push and git-ssh-pull pair is not going away within
+   this timeframe, if ever.  Each of these old-name commands
+   continues to invoke its old-name counterpart on the other
+   end.
+
+
+What to expect after 0.99.8
 ===========================
 
 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
 -------------
 
+* Help Jon Loeliger to find place in the documentation to place
+  his drawing.
+
 * 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.
 
-* Link howto docs from the git.txt page. [DONE]
-
-* Update the SubmittingPatches document to add MUA specific
-  hints on how to disable unwanted MIME and flowed-text by
-  collecting past list postings [DONE].
-
-* Accept patches from people who were hit by shiny blue bat to
-  update the SubmittingPatches [ONGOING].
-
 * 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.
-
-* Review the existing docs and see if the repository
-  organization needs to be clarified further [STILL NEEDSWORK].
-
-* Update tutorial to cover shared repository style a bit more
-  [DONE].
+  support for this (but see below about optimized cloning).
 
 * Maybe update tutorial with a toy project that involves two or
   three developers..
 
-* Document the hooks.
-
 * Update tutorial to cover setting up repository hooks to do
   common tasks.
 
-* Get help to properly use asciidoc in tutorial [Heck, ended up
-  learning it myself, DONE].
+* Accept patches to finish missing docs.
 
-* Maybe justify and demonstrate an Octopus in the tutorial
-  [STILL NEEDSWORK].
+* Accept patches to talk about "Whoops, it broke.  What's
+  next?".
 
-* Add Octopus to the glossary [Thanks Johannes, DONE].
+* Accept patches to make formatted tables in asciidoc to work
+  well in both html and man pages (see git-diff(1)).
 
 
 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.
-  [STARTED TESTING PATCH FROM DANIEL]
-
 * We might want to optimize cloning with GIT native transport
   not to explode the pack, and store it in objects/pack instead.
   We would need a tool to generate an idx file out of a pack
@@ -66,138 +70,181 @@ Technical (heavier)
   idea, making the set of packs in repositories everybody has
   different from each other.
 
-* Maybe a pack optimizer.  I am not convinced that packing all
-  objects into a single pack and removing all the existing panck
-  is the right way to go, since that would work against people
-  who already have those packs.
+* Git daemon, when deployed at kernel.org, might turn out to be
+  quite a burden, since it needs to generate customized packs
+  every time a new request comes in.  It may be worthwhile to
+  precompute some packs for popular sets of heads downloaders
+  have and serve that, even if that could give more than the
+  client asks for in some cases.  We will know about this soon
+  enough.
+
+* 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>; Post
+  1.0].
+
+* 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.
 
 * Maybe an Emacs VC backend.
 
+* 'git split-projects'?  This requires updated 'git-rev-list' to
+  skip irrelevant commits.
+  Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>
 
-Technical (milder)
-------------------
+* Look at libified GNU diff CVS seems to use, or libxdiff.
+  [Daniel has his own diff tool almost ready to start
+  integrating and testing; Post 1.0]
 
-* 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]
+* Accept patches to fetch multiple objects by HTTP in parallel.
+  [DONE]
 
-* We still have the same issue with "git fetch".  Fetching into
-  the branch one is on _may_ need to do the same thing as
-  fetching into anonymous head and then do the resolve.  At
-  least it needs a warning. [DONE]
+* Plug-in file-level merges [Post 1.0].
 
-* "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]
+* Per-repository configuration mechanism.
 
-* Encourage concrete proposals to commit log message templates
-  we discussed some time ago.
 
-* Test apply.c patches from Robert Fitzsmons and have them
-  graduate to "master" branch.
+Technical (milder)
+------------------
 
-* Bug Ryan and work with him to update send-email easier to use.
-  [Resurrected it for Debian build.]
+* Funny tag names and curl library.
 
-* Look at portability fixes from Jason Riedy
+  curl 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID**'
 
-    http://www.cs.berkeley.edu/~ejr/gits/git.git#portable 
+* Review the Makefile variables and exporting rules for them,
+  while looking at prefix passing by Kai Ruemmler [DONE].
 
-  [Applied.  Burned by one of them and backed out, but otherwise
-  looks OK.]
+* Review the 'sparce object database' change by Linus and move
+  the first phase of it to the "master" branch [DONE].
 
-* Accept patches to cause "read-tree -u" delete a directory when
-  it makes it empty.
+* Decide on mmap().  I am inclined to just stick to mmap
+  replacement by Johannes Schindelin and do nothing else right
+  now, except perhaps drop the writing-back support [DONE].
 
-* Perhaps accept patches to introduce the concept of "patch flow
-  expressed as ref mappings" Josef has been advocating about.
+* Revisit Santi's patch to move commit temorary files out of the
+  working tree toplevel [DONE].
 
-* Perhaps accept patches to do undo/redo.
+* More generally, review the use of temporary files again.
+  Assuming writable $GIT_DIR is more acceptable, but the
+  working tree toplevel may not be in a rare usage pattern.
 
-* MIMEified applymbox to grok B and Q encodings in headers and
-  turn them into UTF-8; unwrap QP; explode multipart.
-  [DONE. waiting for a bug to happen ;-) ]
+* Perhaps accept more "want"s in upload-pack and do something
+  intelligent about it.
 
-* Maybe grok PGP signed text/plain in applymbox as well.
+* Perhaps detect cloning request in upload-pack and cache the
+  result for next cloning request until any of our refs change.
 
-* Perhaps a tool to revert a single file to pre-modification
-  state?  git-cat-file blob `git-ls-files | grep foo` >foo or
-  git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
-  the command be called?  git-revert is taken so is
-  git-checkout.
+* Perhaps send less "want"s from fetch-pack.
+
+* Encourage concrete proposals to commit log message templates
+  we discussed some time ago.
 
-* "git cherry-pick" that applies the patch an existing commit
-  introduces in its ancestry chain, possibly using the 3-way
-  merge machinery. [DONE]
+* Accept patches to cause "read-tree -u" delete a directory when
+  it makes it empty.
 
-* Update rebase using the cherry-pick command. [DONE]
+* Perhaps accept patches to do undo/redo.
 
-* Redo "git revert" using 3-way merge machinery. [DONE]
+* Perhaps accept patch to optionally allow '--fuzz' in
+  'git-apply'.
 
-* A tool to detect, show and prune already merged topic
-  branches.
+* Allow 'git apply' to accept GNU diff 2.7 output that forgets
+  to say '\No newline' if both input ends with incomplete
+  lines.
 
-* Set up an automated documentation rebuilding procedure at
-  kernel.org, using update hook mechanism. [DONE]
+* What to do with TABs and LFs in pathnames without breaking GNU
+  patch?  [Discussion started.]
 
-* Describe automated documentation rebuilding in a howto form
-  [DONE].
+* Maybe grok PGP signed text/plain in applymbox as well.
+
+* Perhaps a tool to revert a single file to pre-modification
+  state?  People with BK background know this operation as
+  'clean'.  'git checkout [-f] ent [path...]' was suggested by
+  Matthias Urlichs which sounds a natural extention to what the
+  command currently does.
 
 * Enhance "git repack" to not always use --all; this would be
   handy if the repository contains wagging heads like "pu" in
   git.git repository.
 
-* Accept and apply "git repack --all" patch, except the part
-  that removes the existing packs. [DONE]
-
 * Internally split the project into non-doc and doc parts; add
   an extra root for the doc part and merge from it; move the
   internal doc source to a separate repository, like the +Meta
   repository; experiment if this results in a reasonable
   workflow, and document it in howto form if it does.
 
-* Add names to all nodes in show-branch [DONE].
+  The point is to make it possible to fork that part off to
+  somebody else; then I do not have to maintain Documentation
+  directory myself anymore, just like I simply slurp the latest
+  gitk from Paul and not worry about it ;-).
+
+* Make rebase restartable; instead of skipping what cannot be
+  automatically forward ported, leave the conflicts in the work
+  tree, have the user resolve it, and then restart from where it
+  left off.
 
-* Option to limit rename detection for more than N paths.
+* 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].
+
+* Updated git-changes-script Jeff Garzik needs [Inquiry for
+  external spec sent out with a quick hack.  Will know if that
+  is what he needs soon enough].
+
+* An mechanism to ignore filesystem mode bits altogether.
 
 
 Technical (trivial)
 -------------------
 
-* Look at and merge Debian fixes from Tommi [Done].
+* short SHA1 naming is not enforcing uniqueness.  Should fix [DONE].
 
-* Perhaps "git branch -d" to delete a branch.
+* 'git repack' can be DOSed.  Should fix [DONE].
 
-* Remove "git clone-dumb-http".
+* Stop installing the old-name symlinks [POSTPONED, but before 1.0].
 
-* We would want test scripts for the relative directory path
-  stuff Linus has been working on.  So far, the following
-  commands should be usable with relative directory paths:
+* 'git merge-projects'?
 
-    update-cache
-    ls-files
-    diff-files
-    diff-cache
-    diff-tree
-    rev-list
+  Subject: Re: Merges without bases
+  References: <1125004228.4110.20.camel@localhost.localdomain>
+  Date: Thu, 25 Aug 2005 15:26:36 -0700
+  Message-ID: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>
 
+* 'git lost-and-found'?  Link dangling commits found by
+  fsck-objects under $GIT_DIR/refs/lost-found/.  Then
+  show-branch or gitk can be used to find any lost commit. [A
+  feeler patch sent out. Very underwhelming response X-<.]
 
-Initial repository Gotchas
---------------------------
+  Do not name it /lost+found/; that would probably confuse
+  things that mistake it a mount point (not our code but
+  somebody else's).
 
-* `git fetch foo:bar` works OK, but `git checkout bar`
-  afterwards does not (missing `.git/HEAD`)
-  
-* `git commit -s` did not add signoff for initial commit [DONE].
+* Add simple globbing rules to git-show-branch so that I can
+  say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
+  ko-rc are in refs/tags/).
 
-* `git status` does not work well when missing `.git/HEAD` [DONE].
+* We would want test scripts for the relative directory path
+  stuff Linus has been working on.  So far, the following
+  commands should be usable with relative directory paths:
 
-* `git log` either; git-log-script uses die which does not exist
-  [DONE].
+    git-update-index
+    git-ls-files
+    git-diff-files
+    git-diff-index
+    git-diff-tree
+    git-rev-list
+    git-rev-parse
+
+* In a freashly created empty repository, `git fetch foo:bar`
+  works OK, but `git checkout bar` afterwards does not (missing
+  `.git/HEAD`).
 
 \f
 Local Variables: